| 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. |