| 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 the 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 (!SELECT_MEMORY_MODEL && ARCH_SPARSEMEM_ENABLE) || 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 cannot |
| 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 | bool |
| 105 | |
| 106 | # |
| 107 | # Architecture 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 | config SPARSEMEM_VMEMMAP_ENABLE |
| 116 | bool |
| 117 | |
| 118 | config SPARSEMEM_ALLOC_MEM_MAP_TOGETHER |
| 119 | def_bool y |
| 120 | depends on SPARSEMEM && X86_64 |
| 121 | |
| 122 | config SPARSEMEM_VMEMMAP |
| 123 | bool "Sparse Memory virtual memmap" |
| 124 | depends on SPARSEMEM && SPARSEMEM_VMEMMAP_ENABLE |
| 125 | default y |
| 126 | help |
| 127 | SPARSEMEM_VMEMMAP uses a virtually mapped memmap to optimise |
| 128 | pfn_to_page and page_to_pfn operations. This is the most |
| 129 | efficient option when sufficient kernel resources are available. |
| 130 | |
| 131 | config HAVE_MEMBLOCK |
| 132 | boolean |
| 133 | |
| 134 | # eventually, we can have this option just 'select SPARSEMEM' |
| 135 | config MEMORY_HOTPLUG |
| 136 | bool "Allow for memory hot-add" |
| 137 | depends on SPARSEMEM || X86_64_ACPI_NUMA |
| 138 | depends on HOTPLUG && ARCH_ENABLE_MEMORY_HOTPLUG |
| 139 | depends on (IA64 || X86 || PPC_BOOK3S_64 || SUPERH || S390) |
| 140 | |
| 141 | config MEMORY_HOTPLUG_SPARSE |
| 142 | def_bool y |
| 143 | depends on SPARSEMEM && MEMORY_HOTPLUG |
| 144 | |
| 145 | config MEMORY_HOTREMOVE |
| 146 | bool "Allow for memory hot remove" |
| 147 | depends on MEMORY_HOTPLUG && ARCH_ENABLE_MEMORY_HOTREMOVE |
| 148 | depends on MIGRATION |
| 149 | |
| 150 | # |
| 151 | # If we have space for more page flags then we can enable additional |
| 152 | # optimizations and functionality. |
| 153 | # |
| 154 | # Regular Sparsemem takes page flag bits for the sectionid if it does not |
| 155 | # use a virtual memmap. Disable extended page flags for 32 bit platforms |
| 156 | # that require the use of a sectionid in the page flags. |
| 157 | # |
| 158 | config PAGEFLAGS_EXTENDED |
| 159 | def_bool y |
| 160 | depends on 64BIT || SPARSEMEM_VMEMMAP || !SPARSEMEM |
| 161 | |
| 162 | # Heavily threaded applications may benefit from splitting the mm-wide |
| 163 | # page_table_lock, so that faults on different parts of the user address |
| 164 | # space can be handled with less contention: split it at this NR_CPUS. |
| 165 | # Default to 4 for wider testing, though 8 might be more appropriate. |
| 166 | # ARM's adjust_pte (unused if VIPT) depends on mm-wide page_table_lock. |
| 167 | # PA-RISC 7xxx's spinlock_t would enlarge struct page from 32 to 44 bytes. |
| 168 | # DEBUG_SPINLOCK and DEBUG_LOCK_ALLOC spinlock_t also enlarge struct page. |
| 169 | # |
| 170 | config SPLIT_PTLOCK_CPUS |
| 171 | int |
| 172 | default "999999" if ARM && !CPU_CACHE_VIPT |
| 173 | default "999999" if PARISC && !PA20 |
| 174 | default "999999" if DEBUG_SPINLOCK || DEBUG_LOCK_ALLOC |
| 175 | default "4" |
| 176 | |
| 177 | # |
| 178 | # support for memory compaction |
| 179 | config COMPACTION |
| 180 | bool "Allow for memory compaction" |
| 181 | select MIGRATION |
| 182 | depends on MMU |
| 183 | help |
| 184 | Allows the compaction of memory for the allocation of huge pages. |
| 185 | |
| 186 | # |
| 187 | # support for page migration |
| 188 | # |
| 189 | config MIGRATION |
| 190 | bool "Page migration" |
| 191 | def_bool y |
| 192 | depends on NUMA || ARCH_ENABLE_MEMORY_HOTREMOVE || COMPACTION |
| 193 | help |
| 194 | Allows the migration of the physical location of pages of processes |
| 195 | while the virtual addresses are not changed. This is useful in |
| 196 | two situations. The first is on NUMA systems to put pages nearer |
| 197 | to the processors accessing. The second is when allocating huge |
| 198 | pages as migration can relocate pages to satisfy a huge page |
| 199 | allocation instead of reclaiming. |
| 200 | |
| 201 | config PHYS_ADDR_T_64BIT |
| 202 | def_bool 64BIT || ARCH_PHYS_ADDR_T_64BIT |
| 203 | |
| 204 | config ZONE_DMA_FLAG |
| 205 | int |
| 206 | default "0" if !ZONE_DMA |
| 207 | default "1" |
| 208 | |
| 209 | config BOUNCE |
| 210 | def_bool y |
| 211 | depends on BLOCK && MMU && (ZONE_DMA || HIGHMEM) |
| 212 | |
| 213 | config NR_QUICK |
| 214 | int |
| 215 | depends on QUICKLIST |
| 216 | default "2" if AVR32 |
| 217 | default "1" |
| 218 | |
| 219 | config VIRT_TO_BUS |
| 220 | def_bool y |
| 221 | depends on !ARCH_NO_VIRT_TO_BUS |
| 222 | |
| 223 | config MMU_NOTIFIER |
| 224 | bool |
| 225 | |
| 226 | config KSM |
| 227 | bool "Enable KSM for page merging" |
| 228 | depends on MMU |
| 229 | help |
| 230 | Enable Kernel Samepage Merging: KSM periodically scans those areas |
| 231 | of an application's address space that an app has advised may be |
| 232 | mergeable. When it finds pages of identical content, it replaces |
| 233 | the many instances by a single page with that content, so |
| 234 | saving memory until one or another app needs to modify the content. |
| 235 | Recommended for use with KVM, or with other duplicative applications. |
| 236 | See Documentation/vm/ksm.txt for more information: KSM is inactive |
| 237 | until a program has madvised that an area is MADV_MERGEABLE, and |
| 238 | root has set /sys/kernel/mm/ksm/run to 1 (if CONFIG_SYSFS is set). |
| 239 | |
| 240 | config DEFAULT_MMAP_MIN_ADDR |
| 241 | int "Low address space to protect from user allocation" |
| 242 | depends on MMU |
| 243 | default 4096 |
| 244 | help |
| 245 | This is the portion of low virtual memory which should be protected |
| 246 | from userspace allocation. Keeping a user from writing to low pages |
| 247 | can help reduce the impact of kernel NULL pointer bugs. |
| 248 | |
| 249 | For most ia64, ppc64 and x86 users with lots of address space |
| 250 | a value of 65536 is reasonable and should cause no problems. |
| 251 | On arm and other archs it should not be higher than 32768. |
| 252 | Programs which use vm86 functionality or have some need to map |
| 253 | this low address space will need CAP_SYS_RAWIO or disable this |
| 254 | protection by setting the value to 0. |
| 255 | |
| 256 | This value can be changed after boot using the |
| 257 | /proc/sys/vm/mmap_min_addr tunable. |
| 258 | |
| 259 | config ARCH_SUPPORTS_MEMORY_FAILURE |
| 260 | bool |
| 261 | |
| 262 | config MEMORY_FAILURE |
| 263 | depends on MMU |
| 264 | depends on ARCH_SUPPORTS_MEMORY_FAILURE |
| 265 | bool "Enable recovery from hardware memory errors" |
| 266 | help |
| 267 | Enables code to recover from some memory failures on systems |
| 268 | with MCA recovery. This allows a system to continue running |
| 269 | even when some of its memory has uncorrected errors. This requires |
| 270 | special hardware support and typically ECC memory. |
| 271 | |
| 272 | config HWPOISON_INJECT |
| 273 | tristate "HWPoison pages injector" |
| 274 | depends on MEMORY_FAILURE && DEBUG_KERNEL && PROC_FS |
| 275 | select PROC_PAGE_MONITOR |
| 276 | |
| 277 | config NOMMU_INITIAL_TRIM_EXCESS |
| 278 | int "Turn on mmap() excess space trimming before booting" |
| 279 | depends on !MMU |
| 280 | default 1 |
| 281 | help |
| 282 | The NOMMU mmap() frequently needs to allocate large contiguous chunks |
| 283 | of memory on which to store mappings, but it can only ask the system |
| 284 | allocator for chunks in 2^N*PAGE_SIZE amounts - which is frequently |
| 285 | more than it requires. To deal with this, mmap() is able to trim off |
| 286 | the excess and return it to the allocator. |
| 287 | |
| 288 | If trimming is enabled, the excess is trimmed off and returned to the |
| 289 | system allocator, which can cause extra fragmentation, particularly |
| 290 | if there are a lot of transient processes. |
| 291 | |
| 292 | If trimming is disabled, the excess is kept, but not used, which for |
| 293 | long-term mappings means that the space is wasted. |
| 294 | |
| 295 | Trimming can be dynamically controlled through a sysctl option |
| 296 | (/proc/sys/vm/nr_trim_pages) which specifies the minimum number of |
| 297 | excess pages there must be before trimming should occur, or zero if |
| 298 | no trimming is to occur. |
| 299 | |
| 300 | This option specifies the initial value of this option. The default |
| 301 | of 1 says that all excess pages should be trimmed. |
| 302 | |
| 303 | See Documentation/nommu-mmap.txt for more information. |
| 304 | |
| 305 | config TRANSPARENT_HUGEPAGE |
| 306 | bool "Transparent Hugepage Support" |
| 307 | depends on X86 && MMU |
| 308 | select COMPACTION |
| 309 | help |
| 310 | Transparent Hugepages allows the kernel to use huge pages and |
| 311 | huge tlb transparently to the applications whenever possible. |
| 312 | This feature can improve computing performance to certain |
| 313 | applications by speeding up page faults during memory |
| 314 | allocation, by reducing the number of tlb misses and by speeding |
| 315 | up the pagetable walking. |
| 316 | |
| 317 | If memory constrained on embedded, you may want to say N. |
| 318 | |
| 319 | choice |
| 320 | prompt "Transparent Hugepage Support sysfs defaults" |
| 321 | depends on TRANSPARENT_HUGEPAGE |
| 322 | default TRANSPARENT_HUGEPAGE_ALWAYS |
| 323 | help |
| 324 | Selects the sysfs defaults for Transparent Hugepage Support. |
| 325 | |
| 326 | config TRANSPARENT_HUGEPAGE_ALWAYS |
| 327 | bool "always" |
| 328 | help |
| 329 | Enabling Transparent Hugepage always, can increase the |
| 330 | memory footprint of applications without a guaranteed |
| 331 | benefit but it will work automatically for all applications. |
| 332 | |
| 333 | config TRANSPARENT_HUGEPAGE_MADVISE |
| 334 | bool "madvise" |
| 335 | help |
| 336 | Enabling Transparent Hugepage madvise, will only provide a |
| 337 | performance improvement benefit to the applications using |
| 338 | madvise(MADV_HUGEPAGE) but it won't risk to increase the |
| 339 | memory footprint of applications without a guaranteed |
| 340 | benefit. |
| 341 | endchoice |
| 342 | |
| 343 | # |
| 344 | # UP and nommu archs use km based percpu allocator |
| 345 | # |
| 346 | config NEED_PER_CPU_KM |
| 347 | depends on !SMP |
| 348 | bool |
| 349 | default y |
| 350 | |
| 351 | config CLEANCACHE |
| 352 | bool "Enable cleancache driver to cache clean pages if tmem is present" |
| 353 | default n |
| 354 | help |
| 355 | Cleancache can be thought of as a page-granularity victim cache |
| 356 | for clean pages that the kernel's pageframe replacement algorithm |
| 357 | (PFRA) would like to keep around, but can't since there isn't enough |
| 358 | memory. So when the PFRA "evicts" a page, it first attempts to use |
| 359 | cleancacne code to put the data contained in that page into |
| 360 | "transcendent memory", memory that is not directly accessible or |
| 361 | addressable by the kernel and is of unknown and possibly |
| 362 | time-varying size. And when a cleancache-enabled |
| 363 | filesystem wishes to access a page in a file on disk, it first |
| 364 | checks cleancache to see if it already contains it; if it does, |
| 365 | the page is copied into the kernel and a disk access is avoided. |
| 366 | When a transcendent memory driver is available (such as zcache or |
| 367 | Xen transcendent memory), a significant I/O reduction |
| 368 | may be achieved. When none is available, all cleancache calls |
| 369 | are reduced to a single pointer-compare-against-NULL resulting |
| 370 | in a negligible performance hit. |
| 371 | |
| 372 | If unsure, say Y to enable cleancache |