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