| 1 | config SELECT_MEMORY_MODEL |
| 2 | def_bool y |
| 3 | depends on EXPERIMENTAL || ARCH_SELECT_MEMORY_MODEL |
| 4 | |
| 5 | choice |
| 6 | prompt "Memory model" |
| 7 | depends on SELECT_MEMORY_MODEL |
| 8 | default DISCONTIGMEM_MANUAL if ARCH_DISCONTIGMEM_DEFAULT |
| 9 | default SPARSEMEM_MANUAL if ARCH_SPARSEMEM_DEFAULT |
| 10 | default FLATMEM_MANUAL |
| 11 | |
| 12 | config FLATMEM_MANUAL |
| 13 | bool "Flat Memory" |
| 14 | depends on !(ARCH_DISCONTIGMEM_ENABLE || ARCH_SPARSEMEM_ENABLE) || ARCH_FLATMEM_ENABLE |
| 15 | help |
| 16 | This option allows you to change some of the ways that |
| 17 | Linux manages its memory internally. Most users will |
| 18 | only have one option here: FLATMEM. This is normal |
| 19 | and a correct option. |
| 20 | |
| 21 | Some users of more advanced features like NUMA and |
| 22 | memory hotplug may have different options here. |
| 23 | DISCONTIGMEM is an more mature, better tested system, |
| 24 | but is incompatible with memory hotplug and may suffer |
| 25 | decreased performance over SPARSEMEM. If unsure between |
| 26 | "Sparse Memory" and "Discontiguous Memory", choose |
| 27 | "Discontiguous Memory". |
| 28 | |
| 29 | If unsure, choose this option (Flat Memory) over any other. |
| 30 | |
| 31 | config DISCONTIGMEM_MANUAL |
| 32 | bool "Discontiguous Memory" |
| 33 | depends on ARCH_DISCONTIGMEM_ENABLE |
| 34 | help |
| 35 | This option provides enhanced support for discontiguous |
| 36 | memory systems, over FLATMEM. These systems have holes |
| 37 | in their physical address spaces, and this option provides |
| 38 | more efficient handling of these holes. However, the vast |
| 39 | majority of hardware has quite flat address spaces, and |
| 40 | can have degraded performance from extra overhead that |
| 41 | this option imposes. |
| 42 | |
| 43 | Many NUMA configurations will have this as the only option. |
| 44 | |
| 45 | If unsure, choose "Flat Memory" over this option. |
| 46 | |
| 47 | config SPARSEMEM_MANUAL |
| 48 | bool "Sparse Memory" |
| 49 | depends on ARCH_SPARSEMEM_ENABLE |
| 50 | help |
| 51 | This will be the only option for some systems, including |
| 52 | memory hotplug systems. This is normal. |
| 53 | |
| 54 | For many other systems, this will be an alternative to |
| 55 | "Discontiguous Memory". This option provides some potential |
| 56 | performance benefits, along with decreased code complexity, |
| 57 | but it is newer, and more experimental. |
| 58 | |
| 59 | If unsure, choose "Discontiguous Memory" or "Flat Memory" |
| 60 | over this option. |
| 61 | |
| 62 | endchoice |
| 63 | |
| 64 | config DISCONTIGMEM |
| 65 | def_bool y |
| 66 | depends on (!SELECT_MEMORY_MODEL && ARCH_DISCONTIGMEM_ENABLE) || DISCONTIGMEM_MANUAL |
| 67 | |
| 68 | config SPARSEMEM |
| 69 | def_bool y |
| 70 | depends on SPARSEMEM_MANUAL |
| 71 | |
| 72 | config FLATMEM |
| 73 | def_bool y |
| 74 | depends on (!DISCONTIGMEM && !SPARSEMEM) || FLATMEM_MANUAL |
| 75 | |
| 76 | config FLAT_NODE_MEM_MAP |
| 77 | def_bool y |
| 78 | depends on !SPARSEMEM |
| 79 | |
| 80 | # |
| 81 | # Both the NUMA code and DISCONTIGMEM use arrays of pg_data_t's |
| 82 | # to represent different areas of memory. This variable allows |
| 83 | # those dependencies to exist individually. |
| 84 | # |
| 85 | config NEED_MULTIPLE_NODES |
| 86 | def_bool y |
| 87 | depends on DISCONTIGMEM || NUMA |
| 88 | |
| 89 | config HAVE_MEMORY_PRESENT |
| 90 | def_bool y |
| 91 | depends on ARCH_HAVE_MEMORY_PRESENT || SPARSEMEM |
| 92 | |
| 93 | # |
| 94 | # SPARSEMEM_EXTREME (which is the default) does some bootmem |
| 95 | # allocations when memory_present() is called. If this can not |
| 96 | # be done on your architecture, select this option. However, |
| 97 | # statically allocating the mem_section[] array can potentially |
| 98 | # consume vast quantities of .bss, so be careful. |
| 99 | # |
| 100 | # This option will also potentially produce smaller runtime code |
| 101 | # with gcc 3.4 and later. |
| 102 | # |
| 103 | config SPARSEMEM_STATIC |
| 104 | def_bool n |
| 105 | |
| 106 | # |
| 107 | # Architectecture platforms which require a two level mem_section in SPARSEMEM |
| 108 | # must select this option. This is usually for architecture platforms with |
| 109 | # an extremely sparse physical address space. |
| 110 | # |
| 111 | config SPARSEMEM_EXTREME |
| 112 | def_bool y |
| 113 | depends on SPARSEMEM && !SPARSEMEM_STATIC |
| 114 | |
| 115 | # eventually, we can have this option just 'select SPARSEMEM' |
| 116 | config MEMORY_HOTPLUG |
| 117 | bool "Allow for memory hot-add" |
| 118 | depends on SPARSEMEM && HOTPLUG && !SOFTWARE_SUSPEND |
| 119 | |
| 120 | comment "Memory hotplug is currently incompatible with Software Suspend" |
| 121 | depends on SPARSEMEM && HOTPLUG && SOFTWARE_SUSPEND |
| 122 | |
| 123 | # Heavily threaded applications may benefit from splitting the mm-wide |
| 124 | # page_table_lock, so that faults on different parts of the user address |
| 125 | # space can be handled with less contention: split it at this NR_CPUS. |
| 126 | # Default to 4 for wider testing, though 8 might be more appropriate. |
| 127 | # ARM's adjust_pte (unused if VIPT) depends on mm-wide page_table_lock. |
| 128 | # PA-RISC 7xxx's spinlock_t would enlarge struct page from 32 to 44 bytes. |
| 129 | # |
| 130 | config SPLIT_PTLOCK_CPUS |
| 131 | int |
| 132 | default "4096" if ARM && !CPU_CACHE_VIPT |
| 133 | default "4096" if PARISC && !PA20 |
| 134 | default "4" |
| 135 | |
| 136 | # |
| 137 | # support for page migration |
| 138 | # |
| 139 | config MIGRATION |
| 140 | bool "Page migration" |
| 141 | def_bool y if NUMA |
| 142 | depends on SWAP && NUMA |
| 143 | help |
| 144 | Allows the migration of the physical location of pages of processes |
| 145 | while the virtual addresses are not changed. This is useful for |
| 146 | example on NUMA systems to put pages nearer to the processors accessing |
| 147 | the page. |