| config SELECT_MEMORY_MODEL | |
| def_bool y | |
| depends on EXPERIMENTAL || ARCH_SELECT_MEMORY_MODEL | |
| choice | |
| prompt "Memory model" | |
| depends on SELECT_MEMORY_MODEL | |
| default DISCONTIGMEM_MANUAL if ARCH_DISCONTIGMEM_DEFAULT | |
| default SPARSEMEM_MANUAL if ARCH_SPARSEMEM_DEFAULT | |
| default FLATMEM_MANUAL | |
| config FLATMEM_MANUAL | |
| bool "Flat Memory" | |
| depends on !(ARCH_DISCONTIGMEM_ENABLE || ARCH_SPARSEMEM_ENABLE) || ARCH_FLATMEM_ENABLE | |
| help | |
| This option allows you to change some of the ways that | |
| Linux manages its memory internally. Most users will | |
| only have one option here: FLATMEM. This is normal | |
| and a correct option. | |
| Some users of more advanced features like NUMA and | |
| memory hotplug may have different options here. | |
| DISCONTIGMEM is an more mature, better tested system, | |
| but is incompatible with memory hotplug and may suffer | |
| decreased performance over SPARSEMEM. If unsure between | |
| "Sparse Memory" and "Discontiguous Memory", choose | |
| "Discontiguous Memory". | |
| If unsure, choose this option (Flat Memory) over any other. | |
| config DISCONTIGMEM_MANUAL | |
| bool "Discontiguous Memory" | |
| depends on ARCH_DISCONTIGMEM_ENABLE | |
| help | |
| This option provides enhanced support for discontiguous | |
| memory systems, over FLATMEM. These systems have holes | |
| in their physical address spaces, and this option provides | |
| more efficient handling of these holes. However, the vast | |
| majority of hardware has quite flat address spaces, and | |
| can have degraded performance from extra overhead that | |
| this option imposes. | |
| Many NUMA configurations will have this as the only option. | |
| If unsure, choose "Flat Memory" over this option. | |
| config SPARSEMEM_MANUAL | |
| bool "Sparse Memory" | |
| depends on ARCH_SPARSEMEM_ENABLE | |
| help | |
| This will be the only option for some systems, including | |
| memory hotplug systems. This is normal. | |
| For many other systems, this will be an alternative to | |
| "Discontiguous Memory". This option provides some potential | |
| performance benefits, along with decreased code complexity, | |
| but it is newer, and more experimental. | |
| If unsure, choose "Discontiguous Memory" or "Flat Memory" | |
| over this option. | |
| endchoice | |
| config DISCONTIGMEM | |
| def_bool y | |
| depends on (!SELECT_MEMORY_MODEL && ARCH_DISCONTIGMEM_ENABLE) || DISCONTIGMEM_MANUAL | |
| config SPARSEMEM | |
| def_bool y | |
| depends on SPARSEMEM_MANUAL | |
| config FLATMEM | |
| def_bool y | |
| depends on (!DISCONTIGMEM && !SPARSEMEM) || FLATMEM_MANUAL | |
| config FLAT_NODE_MEM_MAP | |
| def_bool y | |
| depends on !SPARSEMEM | |
| # | |
| # Both the NUMA code and DISCONTIGMEM use arrays of pg_data_t's | |
| # to represent different areas of memory. This variable allows | |
| # those dependencies to exist individually. | |
| # | |
| config NEED_MULTIPLE_NODES | |
| def_bool y | |
| depends on DISCONTIGMEM || NUMA | |
| config HAVE_MEMORY_PRESENT | |
| def_bool y | |
| depends on ARCH_HAVE_MEMORY_PRESENT || SPARSEMEM | |
| # | |
| # SPARSEMEM_EXTREME (which is the default) does some bootmem | |
| # allocations when memory_present() is called. If this can not | |
| # be done on your architecture, select this option. However, | |
| # statically allocating the mem_section[] array can potentially | |
| # consume vast quantities of .bss, so be careful. | |
| # | |
| # This option will also potentially produce smaller runtime code | |
| # with gcc 3.4 and later. | |
| # | |
| config SPARSEMEM_STATIC | |
| def_bool n | |
| # | |
| # Architectecture platforms which require a two level mem_section in SPARSEMEM | |
| # must select this option. This is usually for architecture platforms with | |
| # an extremely sparse physical address space. | |
| # | |
| config SPARSEMEM_EXTREME | |
| def_bool y | |
| depends on SPARSEMEM && !SPARSEMEM_STATIC | |
| # eventually, we can have this option just 'select SPARSEMEM' | |
| config MEMORY_HOTPLUG | |
| bool "Allow for memory hot-add" | |
| depends on SPARSEMEM && HOTPLUG && !SOFTWARE_SUSPEND | |
| comment "Memory hotplug is currently incompatible with Software Suspend" | |
| depends on SPARSEMEM && HOTPLUG && SOFTWARE_SUSPEND | |
| # Heavily threaded applications may benefit from splitting the mm-wide | |
| # page_table_lock, so that faults on different parts of the user address | |
| # space can be handled with less contention: split it at this NR_CPUS. | |
| # Default to 4 for wider testing, though 8 might be more appropriate. | |
| # ARM's adjust_pte (unused if VIPT) depends on mm-wide page_table_lock. | |
| # PA-RISC 7xxx's spinlock_t would enlarge struct page from 32 to 44 bytes. | |
| # | |
| config SPLIT_PTLOCK_CPUS | |
| int | |
| default "4096" if ARM && !CPU_CACHE_VIPT | |
| default "4096" if PARISC && !PA20 | |
| default "4" | |
| # | |
| # support for page migration | |
| # | |
| config MIGRATION | |
| bool "Page migration" | |
| def_bool y if NUMA | |
| depends on SWAP && NUMA | |
| help | |
| Allows the migration of the physical location of pages of processes | |
| while the virtual addresses are not changed. This is useful for | |
| example on NUMA systems to put pages nearer to the processors accessing | |
| the page. |