]>
Commit | Line | Data |
---|---|---|
e1785e85 DH |
1 | config SELECT_MEMORY_MODEL |
2 | def_bool y | |
a8826eeb | 3 | depends on ARCH_SELECT_MEMORY_MODEL |
e1785e85 | 4 | |
3a9da765 DH |
5 | choice |
6 | prompt "Memory model" | |
e1785e85 DH |
7 | depends on SELECT_MEMORY_MODEL |
8 | default DISCONTIGMEM_MANUAL if ARCH_DISCONTIGMEM_DEFAULT | |
d41dee36 | 9 | default SPARSEMEM_MANUAL if ARCH_SPARSEMEM_DEFAULT |
e1785e85 | 10 | default FLATMEM_MANUAL |
3a9da765 | 11 | |
e1785e85 | 12 | config FLATMEM_MANUAL |
3a9da765 | 13 | bool "Flat Memory" |
c898ec16 | 14 | depends on !(ARCH_DISCONTIGMEM_ENABLE || ARCH_SPARSEMEM_ENABLE) || ARCH_FLATMEM_ENABLE |
3a9da765 DH |
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 | ||
d41dee36 AW |
21 | Some users of more advanced features like NUMA and |
22 | memory hotplug may have different options here. | |
18f65332 | 23 | DISCONTIGMEM is a more mature, better tested system, |
d41dee36 AW |
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. | |
3a9da765 | 30 | |
e1785e85 | 31 | config DISCONTIGMEM_MANUAL |
f3519f91 | 32 | bool "Discontiguous Memory" |
3a9da765 DH |
33 | depends on ARCH_DISCONTIGMEM_ENABLE |
34 | help | |
785dcd44 DH |
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 | |
ad3d0a38 | 40 | can have degraded performance from the extra overhead that |
785dcd44 DH |
41 | this option imposes. |
42 | ||
43 | Many NUMA configurations will have this as the only option. | |
44 | ||
3a9da765 DH |
45 | If unsure, choose "Flat Memory" over this option. |
46 | ||
d41dee36 AW |
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 | |
f3519f91 | 55 | "Discontiguous Memory". This option provides some potential |
d41dee36 AW |
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 | ||
3a9da765 DH |
62 | endchoice |
63 | ||
e1785e85 DH |
64 | config DISCONTIGMEM |
65 | def_bool y | |
66 | depends on (!SELECT_MEMORY_MODEL && ARCH_DISCONTIGMEM_ENABLE) || DISCONTIGMEM_MANUAL | |
67 | ||
d41dee36 AW |
68 | config SPARSEMEM |
69 | def_bool y | |
1a83e175 | 70 | depends on (!SELECT_MEMORY_MODEL && ARCH_SPARSEMEM_ENABLE) || SPARSEMEM_MANUAL |
d41dee36 | 71 | |
e1785e85 DH |
72 | config FLATMEM |
73 | def_bool y | |
d41dee36 AW |
74 | depends on (!DISCONTIGMEM && !SPARSEMEM) || FLATMEM_MANUAL |
75 | ||
76 | config FLAT_NODE_MEM_MAP | |
77 | def_bool y | |
78 | depends on !SPARSEMEM | |
e1785e85 | 79 | |
93b7504e DH |
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 | |
af705362 AW |
88 | |
89 | config HAVE_MEMORY_PRESENT | |
90 | def_bool y | |
d41dee36 | 91 | depends on ARCH_HAVE_MEMORY_PRESENT || SPARSEMEM |
802f192e | 92 | |
3e347261 BP |
93 | # |
94 | # SPARSEMEM_EXTREME (which is the default) does some bootmem | |
84eb8d06 | 95 | # allocations when memory_present() is called. If this cannot |
3e347261 BP |
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 | |
9ba16087 | 104 | bool |
3e347261 | 105 | |
802f192e | 106 | # |
44c09201 | 107 | # Architecture platforms which require a two level mem_section in SPARSEMEM |
802f192e BP |
108 | # must select this option. This is usually for architecture platforms with |
109 | # an extremely sparse physical address space. | |
110 | # | |
3e347261 BP |
111 | config SPARSEMEM_EXTREME |
112 | def_bool y | |
113 | depends on SPARSEMEM && !SPARSEMEM_STATIC | |
4c21e2f2 | 114 | |
29c71111 | 115 | config SPARSEMEM_VMEMMAP_ENABLE |
9ba16087 | 116 | bool |
29c71111 | 117 | |
9bdac914 YL |
118 | config SPARSEMEM_ALLOC_MEM_MAP_TOGETHER |
119 | def_bool y | |
120 | depends on SPARSEMEM && X86_64 | |
121 | ||
29c71111 | 122 | config SPARSEMEM_VMEMMAP |
a5ee6daa GL |
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. | |
29c71111 | 130 | |
95f72d1e | 131 | config HAVE_MEMBLOCK |
6341e62b | 132 | bool |
95f72d1e | 133 | |
7c0caeb8 | 134 | config HAVE_MEMBLOCK_NODE_MAP |
6341e62b | 135 | bool |
7c0caeb8 | 136 | |
70210ed9 | 137 | config HAVE_MEMBLOCK_PHYS_MAP |
6341e62b | 138 | bool |
70210ed9 | 139 | |
2947ba05 | 140 | config HAVE_GENERIC_GUP |
6341e62b | 141 | bool |
2667f50e | 142 | |
c378ddd5 | 143 | config ARCH_DISCARD_MEMBLOCK |
6341e62b | 144 | bool |
c378ddd5 | 145 | |
66616720 | 146 | config NO_BOOTMEM |
6341e62b | 147 | bool |
66616720 | 148 | |
ee6f509c | 149 | config MEMORY_ISOLATION |
6341e62b | 150 | bool |
ee6f509c | 151 | |
20b2f52b | 152 | config MOVABLE_NODE |
6341e62b | 153 | bool "Enable to assign a node which has only movable memory" |
20b2f52b LJ |
154 | depends on HAVE_MEMBLOCK |
155 | depends on NO_BOOTMEM | |
41a9ada3 | 156 | depends on X86_64 || OF_EARLY_FLATTREE || MEMORY_HOTPLUG |
20b2f52b | 157 | depends on NUMA |
c2974058 TC |
158 | default n |
159 | help | |
160 | Allow a node to have only movable memory. Pages used by the kernel, | |
161 | such as direct mapping pages cannot be migrated. So the corresponding | |
c5320926 TC |
162 | memory device cannot be hotplugged. This option allows the following |
163 | two things: | |
164 | - When the system is booting, node full of hotpluggable memory can | |
165 | be arranged to have only movable memory so that the whole node can | |
166 | be hot-removed. (need movable_node boot option specified). | |
167 | - After the system is up, the option allows users to online all the | |
168 | memory of a node as movable memory so that the whole node can be | |
169 | hot-removed. | |
170 | ||
171 | Users who don't use the memory hotplug feature are fine with this | |
172 | option on since they don't specify movable_node boot option or they | |
173 | don't online memory as movable. | |
c2974058 TC |
174 | |
175 | Say Y here if you want to hotplug a whole node. | |
176 | Say N here if you want kernel to use memory on all nodes evenly. | |
20b2f52b | 177 | |
46723bfa YI |
178 | # |
179 | # Only be set on architectures that have completely implemented memory hotplug | |
180 | # feature. If you are not sure, don't touch it. | |
181 | # | |
182 | config HAVE_BOOTMEM_INFO_NODE | |
183 | def_bool n | |
184 | ||
3947be19 DH |
185 | # eventually, we can have this option just 'select SPARSEMEM' |
186 | config MEMORY_HOTPLUG | |
187 | bool "Allow for memory hot-add" | |
ec69acbb | 188 | depends on SPARSEMEM || X86_64_ACPI_NUMA |
40b31360 | 189 | depends on ARCH_ENABLE_MEMORY_HOTPLUG |
67463e54 | 190 | depends on COMPILE_TEST || !KASAN |
3947be19 | 191 | |
ec69acbb KM |
192 | config MEMORY_HOTPLUG_SPARSE |
193 | def_bool y | |
194 | depends on SPARSEMEM && MEMORY_HOTPLUG | |
195 | ||
8604d9e5 VK |
196 | config MEMORY_HOTPLUG_DEFAULT_ONLINE |
197 | bool "Online the newly added memory blocks by default" | |
198 | default n | |
199 | depends on MEMORY_HOTPLUG | |
200 | help | |
201 | This option sets the default policy setting for memory hotplug | |
202 | onlining policy (/sys/devices/system/memory/auto_online_blocks) which | |
203 | determines what happens to newly added memory regions. Policy setting | |
204 | can always be changed at runtime. | |
205 | See Documentation/memory-hotplug.txt for more information. | |
206 | ||
207 | Say Y here if you want all hot-plugged memory blocks to appear in | |
208 | 'online' state by default. | |
209 | Say N here if you want the default policy to keep all hot-plugged | |
210 | memory blocks in 'offline' state. | |
211 | ||
0c0e6195 KH |
212 | config MEMORY_HOTREMOVE |
213 | bool "Allow for memory hot remove" | |
46723bfa | 214 | select MEMORY_ISOLATION |
f7e3334a | 215 | select HAVE_BOOTMEM_INFO_NODE if (X86_64 || PPC64) |
0c0e6195 KH |
216 | depends on MEMORY_HOTPLUG && ARCH_ENABLE_MEMORY_HOTREMOVE |
217 | depends on MIGRATION | |
218 | ||
4c21e2f2 HD |
219 | # Heavily threaded applications may benefit from splitting the mm-wide |
220 | # page_table_lock, so that faults on different parts of the user address | |
221 | # space can be handled with less contention: split it at this NR_CPUS. | |
222 | # Default to 4 for wider testing, though 8 might be more appropriate. | |
223 | # ARM's adjust_pte (unused if VIPT) depends on mm-wide page_table_lock. | |
7b6ac9df | 224 | # PA-RISC 7xxx's spinlock_t would enlarge struct page from 32 to 44 bytes. |
a70caa8b | 225 | # DEBUG_SPINLOCK and DEBUG_LOCK_ALLOC spinlock_t also enlarge struct page. |
4c21e2f2 HD |
226 | # |
227 | config SPLIT_PTLOCK_CPUS | |
228 | int | |
9164550e | 229 | default "999999" if !MMU |
a70caa8b HD |
230 | default "999999" if ARM && !CPU_CACHE_VIPT |
231 | default "999999" if PARISC && !PA20 | |
4c21e2f2 | 232 | default "4" |
7cbe34cf | 233 | |
e009bb30 | 234 | config ARCH_ENABLE_SPLIT_PMD_PTLOCK |
6341e62b | 235 | bool |
e009bb30 | 236 | |
09316c09 KK |
237 | # |
238 | # support for memory balloon | |
239 | config MEMORY_BALLOON | |
6341e62b | 240 | bool |
09316c09 | 241 | |
18468d93 RA |
242 | # |
243 | # support for memory balloon compaction | |
244 | config BALLOON_COMPACTION | |
245 | bool "Allow for balloon memory compaction/migration" | |
246 | def_bool y | |
09316c09 | 247 | depends on COMPACTION && MEMORY_BALLOON |
18468d93 RA |
248 | help |
249 | Memory fragmentation introduced by ballooning might reduce | |
250 | significantly the number of 2MB contiguous memory blocks that can be | |
251 | used within a guest, thus imposing performance penalties associated | |
252 | with the reduced number of transparent huge pages that could be used | |
253 | by the guest workload. Allowing the compaction & migration for memory | |
254 | pages enlisted as being part of memory balloon devices avoids the | |
255 | scenario aforementioned and helps improving memory defragmentation. | |
256 | ||
e9e96b39 MG |
257 | # |
258 | # support for memory compaction | |
259 | config COMPACTION | |
260 | bool "Allow for memory compaction" | |
05106e6a | 261 | def_bool y |
e9e96b39 | 262 | select MIGRATION |
33a93877 | 263 | depends on MMU |
e9e96b39 | 264 | help |
b32eaf71 MH |
265 | Compaction is the only memory management component to form |
266 | high order (larger physically contiguous) memory blocks | |
267 | reliably. The page allocator relies on compaction heavily and | |
268 | the lack of the feature can lead to unexpected OOM killer | |
269 | invocations for high order memory requests. You shouldn't | |
270 | disable this option unless there really is a strong reason for | |
271 | it and then we would be really interested to hear about that at | |
272 | linux-mm@kvack.org. | |
e9e96b39 | 273 | |
7cbe34cf CL |
274 | # |
275 | # support for page migration | |
276 | # | |
277 | config MIGRATION | |
b20a3503 | 278 | bool "Page migration" |
6c5240ae | 279 | def_bool y |
de32a817 | 280 | depends on (NUMA || ARCH_ENABLE_MEMORY_HOTREMOVE || COMPACTION || CMA) && MMU |
b20a3503 CL |
281 | help |
282 | Allows the migration of the physical location of pages of processes | |
e9e96b39 MG |
283 | while the virtual addresses are not changed. This is useful in |
284 | two situations. The first is on NUMA systems to put pages nearer | |
285 | to the processors accessing. The second is when allocating huge | |
286 | pages as migration can relocate pages to satisfy a huge page | |
287 | allocation instead of reclaiming. | |
6550e07f | 288 | |
c177c81e | 289 | config ARCH_ENABLE_HUGEPAGE_MIGRATION |
6341e62b | 290 | bool |
c177c81e | 291 | |
600715dc JF |
292 | config PHYS_ADDR_T_64BIT |
293 | def_bool 64BIT || ARCH_PHYS_ADDR_T_64BIT | |
294 | ||
2a7326b5 | 295 | config BOUNCE |
9ca24e2e VM |
296 | bool "Enable bounce buffers" |
297 | default y | |
2a7326b5 | 298 | depends on BLOCK && MMU && (ZONE_DMA || HIGHMEM) |
9ca24e2e VM |
299 | help |
300 | Enable bounce buffers for devices that cannot access | |
301 | the full range of memory available to the CPU. Enabled | |
302 | by default when ZONE_DMA or HIGHMEM is selected, but you | |
303 | may say n to override this. | |
2a7326b5 | 304 | |
ffecfd1a DW |
305 | # On the 'tile' arch, USB OHCI needs the bounce pool since tilegx will often |
306 | # have more than 4GB of memory, but we don't currently use the IOTLB to present | |
307 | # a 32-bit address to OHCI. So we need to use a bounce pool instead. | |
ffecfd1a DW |
308 | config NEED_BOUNCE_POOL |
309 | bool | |
debeb297 | 310 | default y if TILE && USB_OHCI_HCD |
ffecfd1a | 311 | |
6225e937 CL |
312 | config NR_QUICK |
313 | int | |
314 | depends on QUICKLIST | |
0176bd3d | 315 | default "2" if AVR32 |
6225e937 | 316 | default "1" |
f057eac0 SR |
317 | |
318 | config VIRT_TO_BUS | |
4febd95a SR |
319 | bool |
320 | help | |
321 | An architecture should select this if it implements the | |
322 | deprecated interface virt_to_bus(). All new architectures | |
323 | should probably not select this. | |
324 | ||
cddb8a5c AA |
325 | |
326 | config MMU_NOTIFIER | |
327 | bool | |
83fe27ea | 328 | select SRCU |
fc4d5c29 | 329 | |
f8af4da3 HD |
330 | config KSM |
331 | bool "Enable KSM for page merging" | |
332 | depends on MMU | |
333 | help | |
334 | Enable Kernel Samepage Merging: KSM periodically scans those areas | |
335 | of an application's address space that an app has advised may be | |
336 | mergeable. When it finds pages of identical content, it replaces | |
d0f209f6 | 337 | the many instances by a single page with that content, so |
f8af4da3 HD |
338 | saving memory until one or another app needs to modify the content. |
339 | Recommended for use with KVM, or with other duplicative applications. | |
c73602ad HD |
340 | See Documentation/vm/ksm.txt for more information: KSM is inactive |
341 | until a program has madvised that an area is MADV_MERGEABLE, and | |
342 | root has set /sys/kernel/mm/ksm/run to 1 (if CONFIG_SYSFS is set). | |
f8af4da3 | 343 | |
e0a94c2a CL |
344 | config DEFAULT_MMAP_MIN_ADDR |
345 | int "Low address space to protect from user allocation" | |
6e141546 | 346 | depends on MMU |
e0a94c2a CL |
347 | default 4096 |
348 | help | |
349 | This is the portion of low virtual memory which should be protected | |
350 | from userspace allocation. Keeping a user from writing to low pages | |
351 | can help reduce the impact of kernel NULL pointer bugs. | |
352 | ||
353 | For most ia64, ppc64 and x86 users with lots of address space | |
354 | a value of 65536 is reasonable and should cause no problems. | |
355 | On arm and other archs it should not be higher than 32768. | |
788084ab EP |
356 | Programs which use vm86 functionality or have some need to map |
357 | this low address space will need CAP_SYS_RAWIO or disable this | |
358 | protection by setting the value to 0. | |
e0a94c2a CL |
359 | |
360 | This value can be changed after boot using the | |
361 | /proc/sys/vm/mmap_min_addr tunable. | |
362 | ||
d949f36f LT |
363 | config ARCH_SUPPORTS_MEMORY_FAILURE |
364 | bool | |
e0a94c2a | 365 | |
6a46079c AK |
366 | config MEMORY_FAILURE |
367 | depends on MMU | |
d949f36f | 368 | depends on ARCH_SUPPORTS_MEMORY_FAILURE |
6a46079c | 369 | bool "Enable recovery from hardware memory errors" |
ee6f509c | 370 | select MEMORY_ISOLATION |
97f0b134 | 371 | select RAS |
6a46079c AK |
372 | help |
373 | Enables code to recover from some memory failures on systems | |
374 | with MCA recovery. This allows a system to continue running | |
375 | even when some of its memory has uncorrected errors. This requires | |
376 | special hardware support and typically ECC memory. | |
377 | ||
cae681fc | 378 | config HWPOISON_INJECT |
413f9efb | 379 | tristate "HWPoison pages injector" |
27df5068 | 380 | depends on MEMORY_FAILURE && DEBUG_KERNEL && PROC_FS |
478c5ffc | 381 | select PROC_PAGE_MONITOR |
cae681fc | 382 | |
fc4d5c29 DH |
383 | config NOMMU_INITIAL_TRIM_EXCESS |
384 | int "Turn on mmap() excess space trimming before booting" | |
385 | depends on !MMU | |
386 | default 1 | |
387 | help | |
388 | The NOMMU mmap() frequently needs to allocate large contiguous chunks | |
389 | of memory on which to store mappings, but it can only ask the system | |
390 | allocator for chunks in 2^N*PAGE_SIZE amounts - which is frequently | |
391 | more than it requires. To deal with this, mmap() is able to trim off | |
392 | the excess and return it to the allocator. | |
393 | ||
394 | If trimming is enabled, the excess is trimmed off and returned to the | |
395 | system allocator, which can cause extra fragmentation, particularly | |
396 | if there are a lot of transient processes. | |
397 | ||
398 | If trimming is disabled, the excess is kept, but not used, which for | |
399 | long-term mappings means that the space is wasted. | |
400 | ||
401 | Trimming can be dynamically controlled through a sysctl option | |
402 | (/proc/sys/vm/nr_trim_pages) which specifies the minimum number of | |
403 | excess pages there must be before trimming should occur, or zero if | |
404 | no trimming is to occur. | |
405 | ||
406 | This option specifies the initial value of this option. The default | |
407 | of 1 says that all excess pages should be trimmed. | |
408 | ||
409 | See Documentation/nommu-mmap.txt for more information. | |
bbddff05 | 410 | |
4c76d9d1 | 411 | config TRANSPARENT_HUGEPAGE |
13ece886 | 412 | bool "Transparent Hugepage Support" |
15626062 | 413 | depends on HAVE_ARCH_TRANSPARENT_HUGEPAGE |
5d689240 | 414 | select COMPACTION |
57578c2e | 415 | select RADIX_TREE_MULTIORDER |
4c76d9d1 AA |
416 | help |
417 | Transparent Hugepages allows the kernel to use huge pages and | |
418 | huge tlb transparently to the applications whenever possible. | |
419 | This feature can improve computing performance to certain | |
420 | applications by speeding up page faults during memory | |
421 | allocation, by reducing the number of tlb misses and by speeding | |
422 | up the pagetable walking. | |
423 | ||
424 | If memory constrained on embedded, you may want to say N. | |
425 | ||
13ece886 AA |
426 | choice |
427 | prompt "Transparent Hugepage Support sysfs defaults" | |
428 | depends on TRANSPARENT_HUGEPAGE | |
429 | default TRANSPARENT_HUGEPAGE_ALWAYS | |
430 | help | |
431 | Selects the sysfs defaults for Transparent Hugepage Support. | |
432 | ||
433 | config TRANSPARENT_HUGEPAGE_ALWAYS | |
434 | bool "always" | |
435 | help | |
436 | Enabling Transparent Hugepage always, can increase the | |
437 | memory footprint of applications without a guaranteed | |
438 | benefit but it will work automatically for all applications. | |
439 | ||
440 | config TRANSPARENT_HUGEPAGE_MADVISE | |
441 | bool "madvise" | |
442 | help | |
443 | Enabling Transparent Hugepage madvise, will only provide a | |
444 | performance improvement benefit to the applications using | |
445 | madvise(MADV_HUGEPAGE) but it won't risk to increase the | |
446 | memory footprint of applications without a guaranteed | |
447 | benefit. | |
448 | endchoice | |
449 | ||
e496cf3d KS |
450 | config TRANSPARENT_HUGE_PAGECACHE |
451 | def_bool y | |
953c66c2 | 452 | depends on TRANSPARENT_HUGEPAGE |
e496cf3d | 453 | |
bbddff05 TH |
454 | # |
455 | # UP and nommu archs use km based percpu allocator | |
456 | # | |
457 | config NEED_PER_CPU_KM | |
458 | depends on !SMP | |
459 | bool | |
460 | default y | |
077b1f83 DM |
461 | |
462 | config CLEANCACHE | |
463 | bool "Enable cleancache driver to cache clean pages if tmem is present" | |
464 | default n | |
465 | help | |
466 | Cleancache can be thought of as a page-granularity victim cache | |
467 | for clean pages that the kernel's pageframe replacement algorithm | |
468 | (PFRA) would like to keep around, but can't since there isn't enough | |
469 | memory. So when the PFRA "evicts" a page, it first attempts to use | |
140a1ef2 | 470 | cleancache code to put the data contained in that page into |
077b1f83 DM |
471 | "transcendent memory", memory that is not directly accessible or |
472 | addressable by the kernel and is of unknown and possibly | |
473 | time-varying size. And when a cleancache-enabled | |
474 | filesystem wishes to access a page in a file on disk, it first | |
475 | checks cleancache to see if it already contains it; if it does, | |
476 | the page is copied into the kernel and a disk access is avoided. | |
477 | When a transcendent memory driver is available (such as zcache or | |
478 | Xen transcendent memory), a significant I/O reduction | |
479 | may be achieved. When none is available, all cleancache calls | |
480 | are reduced to a single pointer-compare-against-NULL resulting | |
481 | in a negligible performance hit. | |
482 | ||
483 | If unsure, say Y to enable cleancache | |
27c6aec2 DM |
484 | |
485 | config FRONTSWAP | |
486 | bool "Enable frontswap to cache swap pages if tmem is present" | |
487 | depends on SWAP | |
488 | default n | |
489 | help | |
490 | Frontswap is so named because it can be thought of as the opposite | |
491 | of a "backing" store for a swap device. The data is stored into | |
492 | "transcendent memory", memory that is not directly accessible or | |
493 | addressable by the kernel and is of unknown and possibly | |
494 | time-varying size. When space in transcendent memory is available, | |
495 | a significant swap I/O reduction may be achieved. When none is | |
496 | available, all frontswap calls are reduced to a single pointer- | |
497 | compare-against-NULL resulting in a negligible performance hit | |
498 | and swap data is stored as normal on the matching swap device. | |
499 | ||
500 | If unsure, say Y to enable frontswap. | |
f825c736 AK |
501 | |
502 | config CMA | |
503 | bool "Contiguous Memory Allocator" | |
de32a817 | 504 | depends on HAVE_MEMBLOCK && MMU |
f825c736 AK |
505 | select MIGRATION |
506 | select MEMORY_ISOLATION | |
507 | help | |
508 | This enables the Contiguous Memory Allocator which allows other | |
509 | subsystems to allocate big physically-contiguous blocks of memory. | |
510 | CMA reserves a region of memory and allows only movable pages to | |
511 | be allocated from it. This way, the kernel can use the memory for | |
512 | pagecache and when a subsystem requests for contiguous area, the | |
513 | allocated pages are migrated away to serve the contiguous request. | |
514 | ||
515 | If unsure, say "n". | |
516 | ||
517 | config CMA_DEBUG | |
518 | bool "CMA debug messages (DEVELOPMENT)" | |
519 | depends on DEBUG_KERNEL && CMA | |
520 | help | |
521 | Turns on debug messages in CMA. This produces KERN_DEBUG | |
522 | messages for every CMA call as well as various messages while | |
523 | processing calls such as dma_alloc_from_contiguous(). | |
524 | This option does not affect warning and error messages. | |
bf550fc9 | 525 | |
28b24c1f SL |
526 | config CMA_DEBUGFS |
527 | bool "CMA debugfs interface" | |
528 | depends on CMA && DEBUG_FS | |
529 | help | |
530 | Turns on the DebugFS interface for CMA. | |
531 | ||
a254129e JK |
532 | config CMA_AREAS |
533 | int "Maximum count of the CMA areas" | |
534 | depends on CMA | |
535 | default 7 | |
536 | help | |
537 | CMA allows to create CMA areas for particular purpose, mainly, | |
538 | used as device private area. This parameter sets the maximum | |
539 | number of CMA area in the system. | |
540 | ||
541 | If unsure, leave the default value "7". | |
542 | ||
af8d417a DS |
543 | config MEM_SOFT_DIRTY |
544 | bool "Track memory changes" | |
545 | depends on CHECKPOINT_RESTORE && HAVE_ARCH_SOFT_DIRTY && PROC_FS | |
546 | select PROC_PAGE_MONITOR | |
4e2e2770 | 547 | help |
af8d417a DS |
548 | This option enables memory changes tracking by introducing a |
549 | soft-dirty bit on pte-s. This bit it set when someone writes | |
550 | into a page just as regular dirty bit, but unlike the latter | |
551 | it can be cleared by hands. | |
552 | ||
553 | See Documentation/vm/soft-dirty.txt for more details. | |
4e2e2770 | 554 | |
2b281117 SJ |
555 | config ZSWAP |
556 | bool "Compressed cache for swap pages (EXPERIMENTAL)" | |
557 | depends on FRONTSWAP && CRYPTO=y | |
558 | select CRYPTO_LZO | |
12d79d64 | 559 | select ZPOOL |
2b281117 SJ |
560 | default n |
561 | help | |
562 | A lightweight compressed cache for swap pages. It takes | |
563 | pages that are in the process of being swapped out and attempts to | |
564 | compress them into a dynamically allocated RAM-based memory pool. | |
565 | This can result in a significant I/O reduction on swap device and, | |
566 | in the case where decompressing from RAM is faster that swap device | |
567 | reads, can also improve workload performance. | |
568 | ||
569 | This is marked experimental because it is a new feature (as of | |
570 | v3.11) that interacts heavily with memory reclaim. While these | |
571 | interactions don't cause any known issues on simple memory setups, | |
572 | they have not be fully explored on the large set of potential | |
573 | configurations and workloads that exist. | |
574 | ||
af8d417a DS |
575 | config ZPOOL |
576 | tristate "Common API for compressed memory storage" | |
577 | default n | |
0f8975ec | 578 | help |
af8d417a DS |
579 | Compressed memory storage API. This allows using either zbud or |
580 | zsmalloc. | |
0f8975ec | 581 | |
af8d417a | 582 | config ZBUD |
9a001fc1 | 583 | tristate "Low (Up to 2x) density storage for compressed pages" |
af8d417a DS |
584 | default n |
585 | help | |
586 | A special purpose allocator for storing compressed pages. | |
587 | It is designed to store up to two compressed pages per physical | |
588 | page. While this design limits storage density, it has simple and | |
589 | deterministic reclaim properties that make it preferable to a higher | |
590 | density approach when reclaim will be used. | |
bcf1647d | 591 | |
9a001fc1 VW |
592 | config Z3FOLD |
593 | tristate "Up to 3x density storage for compressed pages" | |
594 | depends on ZPOOL | |
595 | default n | |
596 | help | |
597 | A special purpose allocator for storing compressed pages. | |
598 | It is designed to store up to three compressed pages per physical | |
599 | page. It is a ZBUD derivative so the simplicity and determinism are | |
600 | still there. | |
601 | ||
bcf1647d | 602 | config ZSMALLOC |
d867f203 | 603 | tristate "Memory allocator for compressed pages" |
bcf1647d MK |
604 | depends on MMU |
605 | default n | |
606 | help | |
607 | zsmalloc is a slab-based memory allocator designed to store | |
608 | compressed RAM pages. zsmalloc uses virtual memory mapping | |
609 | in order to reduce fragmentation. However, this results in a | |
610 | non-standard allocator interface where a handle, not a pointer, is | |
611 | returned by an alloc(). This handle must be mapped in order to | |
612 | access the allocated space. | |
613 | ||
614 | config PGTABLE_MAPPING | |
615 | bool "Use page table mapping to access object in zsmalloc" | |
616 | depends on ZSMALLOC | |
617 | help | |
618 | By default, zsmalloc uses a copy-based object mapping method to | |
619 | access allocations that span two pages. However, if a particular | |
620 | architecture (ex, ARM) performs VM mapping faster than copying, | |
621 | then you should select this. This causes zsmalloc to use page table | |
622 | mapping rather than copying for object mapping. | |
623 | ||
2216ee85 BH |
624 | You can check speed with zsmalloc benchmark: |
625 | https://github.com/spartacus06/zsmapbench | |
9e5c33d7 | 626 | |
0f050d99 GM |
627 | config ZSMALLOC_STAT |
628 | bool "Export zsmalloc statistics" | |
629 | depends on ZSMALLOC | |
630 | select DEBUG_FS | |
631 | help | |
632 | This option enables code in the zsmalloc to collect various | |
633 | statistics about whats happening in zsmalloc and exports that | |
634 | information to userspace via debugfs. | |
635 | If unsure, say N. | |
636 | ||
9e5c33d7 MS |
637 | config GENERIC_EARLY_IOREMAP |
638 | bool | |
042d27ac HD |
639 | |
640 | config MAX_STACK_SIZE_MB | |
641 | int "Maximum user stack size for 32-bit processes (MB)" | |
642 | default 80 | |
643 | range 8 256 if METAG | |
644 | range 8 2048 | |
645 | depends on STACK_GROWSUP && (!64BIT || COMPAT) | |
646 | help | |
647 | This is the maximum stack size in Megabytes in the VM layout of 32-bit | |
648 | user processes when the stack grows upwards (currently only on parisc | |
649 | and metag arch). The stack will be located at the highest memory | |
650 | address minus the given value, unless the RLIMIT_STACK hard limit is | |
651 | changed to a smaller value in which case that is used. | |
652 | ||
653 | A sane initial value is 80 MB. | |
3a80a7fa MG |
654 | |
655 | # For architectures that support deferred memory initialisation | |
656 | config ARCH_SUPPORTS_DEFERRED_STRUCT_PAGE_INIT | |
657 | bool | |
658 | ||
659 | config DEFERRED_STRUCT_PAGE_INIT | |
1ce22103 | 660 | bool "Defer initialisation of struct pages to kthreads" |
3a80a7fa MG |
661 | default n |
662 | depends on ARCH_SUPPORTS_DEFERRED_STRUCT_PAGE_INIT | |
11e68567 | 663 | depends on NO_BOOTMEM && MEMORY_HOTPLUG |
95794924 | 664 | depends on !FLATMEM |
3a80a7fa MG |
665 | help |
666 | Ordinarily all struct pages are initialised during early boot in a | |
667 | single thread. On very large machines this can take a considerable | |
668 | amount of time. If this option is set, large machines will bring up | |
669 | a subset of memmap at boot and then initialise the rest in parallel | |
1ce22103 VB |
670 | by starting one-off "pgdatinitX" kernel thread for each node X. This |
671 | has a potential performance impact on processes running early in the | |
672 | lifetime of the system until these kthreads finish the | |
673 | initialisation. | |
033fbae9 | 674 | |
33c3fc71 VD |
675 | config IDLE_PAGE_TRACKING |
676 | bool "Enable idle page tracking" | |
677 | depends on SYSFS && MMU | |
678 | select PAGE_EXTENSION if !64BIT | |
679 | help | |
680 | This feature allows to estimate the amount of user pages that have | |
681 | not been touched during a given period of time. This information can | |
682 | be useful to tune memory cgroup limits and/or for job placement | |
683 | within a compute cluster. | |
684 | ||
685 | See Documentation/vm/idle_page_tracking.txt for more details. | |
686 | ||
033fbae9 | 687 | config ZONE_DEVICE |
c02b6aec | 688 | bool "Device memory (pmem, etc...) hotplug support" |
033fbae9 DW |
689 | depends on MEMORY_HOTPLUG |
690 | depends on MEMORY_HOTREMOVE | |
99490f16 | 691 | depends on SPARSEMEM_VMEMMAP |
033fbae9 DW |
692 | depends on X86_64 #arch_add_memory() comprehends device memory |
693 | ||
694 | help | |
695 | Device memory hotplug support allows for establishing pmem, | |
696 | or other device driver discovered memory regions, in the | |
697 | memmap. This allows pfn_to_page() lookups of otherwise | |
698 | "device-physical" addresses which is needed for using a DAX | |
699 | mapping in an O_DIRECT operation, among other things. | |
700 | ||
701 | If FS_DAX is enabled, then say Y. | |
06a660ad | 702 | |
8025e5dd JK |
703 | config FRAME_VECTOR |
704 | bool | |
63c17fb8 DH |
705 | |
706 | config ARCH_USES_HIGH_VMA_FLAGS | |
707 | bool | |
66d37570 DH |
708 | config ARCH_HAS_PKEYS |
709 | bool |