blob: ea074a9d4958c10d1a7056c24ceefa2a75ed5798
1 | config SELECT_MEMORY_MODEL |
2 | def_bool y |
3 | depends on 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 a 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 | bool |
133 | |
134 | config HAVE_MEMBLOCK_NODE_MAP |
135 | bool |
136 | |
137 | config HAVE_MEMBLOCK_PHYS_MAP |
138 | bool |
139 | |
140 | config HAVE_GENERIC_RCU_GUP |
141 | bool |
142 | |
143 | config ARCH_DISCARD_MEMBLOCK |
144 | bool |
145 | |
146 | config NO_BOOTMEM |
147 | bool |
148 | |
149 | config MEMORY_ISOLATION |
150 | bool |
151 | |
152 | config MOVABLE_NODE |
153 | bool "Enable to assign a node which has only movable memory" |
154 | depends on HAVE_MEMBLOCK |
155 | depends on NO_BOOTMEM |
156 | depends on X86_64 |
157 | depends on NUMA |
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 |
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. |
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. |
177 | |
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 | |
185 | # eventually, we can have this option just 'select SPARSEMEM' |
186 | config MEMORY_HOTPLUG |
187 | bool "Allow for memory hot-add" |
188 | depends on SPARSEMEM || X86_64_ACPI_NUMA |
189 | depends on ARCH_ENABLE_MEMORY_HOTPLUG |
190 | depends on COMPILE_TEST || !KASAN |
191 | |
192 | config MEMORY_HOTPLUG_SPARSE |
193 | def_bool y |
194 | depends on SPARSEMEM && MEMORY_HOTPLUG |
195 | |
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 | |
212 | config MEMORY_HOTREMOVE |
213 | bool "Allow for memory hot remove" |
214 | select MEMORY_ISOLATION |
215 | select HAVE_BOOTMEM_INFO_NODE if (X86_64 || PPC64) |
216 | depends on MEMORY_HOTPLUG && ARCH_ENABLE_MEMORY_HOTREMOVE |
217 | depends on MIGRATION |
218 | |
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. |
224 | # PA-RISC 7xxx's spinlock_t would enlarge struct page from 32 to 44 bytes. |
225 | # DEBUG_SPINLOCK and DEBUG_LOCK_ALLOC spinlock_t also enlarge struct page. |
226 | # |
227 | config SPLIT_PTLOCK_CPUS |
228 | int |
229 | default "999999" if !MMU |
230 | default "999999" if ARM && !CPU_CACHE_VIPT |
231 | default "999999" if PARISC && !PA20 |
232 | default "4" |
233 | |
234 | config ARCH_ENABLE_SPLIT_PMD_PTLOCK |
235 | bool |
236 | |
237 | # |
238 | # support for memory balloon |
239 | config MEMORY_BALLOON |
240 | bool |
241 | |
242 | # |
243 | # support for memory balloon compaction |
244 | config BALLOON_COMPACTION |
245 | bool "Allow for balloon memory compaction/migration" |
246 | def_bool y |
247 | depends on COMPACTION && MEMORY_BALLOON |
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 | |
257 | # |
258 | # support for memory compaction |
259 | config COMPACTION |
260 | bool "Allow for memory compaction" |
261 | def_bool y |
262 | select MIGRATION |
263 | depends on MMU |
264 | help |
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. |
273 | |
274 | # |
275 | # support for page migration |
276 | # |
277 | config MIGRATION |
278 | bool "Page migration" |
279 | def_bool y |
280 | depends on (NUMA || ARCH_ENABLE_MEMORY_HOTREMOVE || COMPACTION || CMA) && MMU |
281 | help |
282 | Allows the migration of the physical location of pages of processes |
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. |
288 | |
289 | config ARCH_ENABLE_HUGEPAGE_MIGRATION |
290 | bool |
291 | |
292 | config PHYS_ADDR_T_64BIT |
293 | def_bool 64BIT || ARCH_PHYS_ADDR_T_64BIT |
294 | |
295 | config BOUNCE |
296 | bool "Enable bounce buffers" |
297 | default y |
298 | depends on BLOCK && MMU && (ZONE_DMA || HIGHMEM) |
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. |
304 | |
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. |
308 | config NEED_BOUNCE_POOL |
309 | bool |
310 | default y if TILE && USB_OHCI_HCD |
311 | |
312 | config NR_QUICK |
313 | int |
314 | depends on QUICKLIST |
315 | default "2" if AVR32 |
316 | default "1" |
317 | |
318 | config VIRT_TO_BUS |
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 | |
325 | |
326 | config MMU_NOTIFIER |
327 | bool |
328 | select SRCU |
329 | |
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 |
337 | the many instances by a single page with that content, so |
338 | saving memory until one or another app needs to modify the content. |
339 | Recommended for use with KVM, or with other duplicative applications. |
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). |
343 | |
344 | config DEFAULT_MMAP_MIN_ADDR |
345 | int "Low address space to protect from user allocation" |
346 | depends on MMU |
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. |
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. |
359 | |
360 | This value can be changed after boot using the |
361 | /proc/sys/vm/mmap_min_addr tunable. |
362 | |
363 | config ARCH_SUPPORTS_MEMORY_FAILURE |
364 | bool |
365 | |
366 | config MEMORY_FAILURE |
367 | depends on MMU |
368 | depends on ARCH_SUPPORTS_MEMORY_FAILURE |
369 | bool "Enable recovery from hardware memory errors" |
370 | select MEMORY_ISOLATION |
371 | select RAS |
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 | |
378 | config HWPOISON_INJECT |
379 | tristate "HWPoison pages injector" |
380 | depends on MEMORY_FAILURE && DEBUG_KERNEL && PROC_FS |
381 | select PROC_PAGE_MONITOR |
382 | |
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. |
410 | |
411 | config TRANSPARENT_HUGEPAGE |
412 | bool "Transparent Hugepage Support" |
413 | depends on HAVE_ARCH_TRANSPARENT_HUGEPAGE |
414 | select COMPACTION |
415 | select RADIX_TREE_MULTIORDER |
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 | |
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 | |
450 | # |
451 | # We don't deposit page tables on file THP mapping, |
452 | # but Power makes use of them to address MMU quirk. |
453 | # |
454 | config TRANSPARENT_HUGE_PAGECACHE |
455 | def_bool y |
456 | depends on TRANSPARENT_HUGEPAGE && !PPC |
457 | |
458 | # |
459 | # UP and nommu archs use km based percpu allocator |
460 | # |
461 | config NEED_PER_CPU_KM |
462 | depends on !SMP |
463 | bool |
464 | default y |
465 | |
466 | config CLEANCACHE |
467 | bool "Enable cleancache driver to cache clean pages if tmem is present" |
468 | default n |
469 | help |
470 | Cleancache can be thought of as a page-granularity victim cache |
471 | for clean pages that the kernel's pageframe replacement algorithm |
472 | (PFRA) would like to keep around, but can't since there isn't enough |
473 | memory. So when the PFRA "evicts" a page, it first attempts to use |
474 | cleancache code to put the data contained in that page 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. And when a cleancache-enabled |
478 | filesystem wishes to access a page in a file on disk, it first |
479 | checks cleancache to see if it already contains it; if it does, |
480 | the page is copied into the kernel and a disk access is avoided. |
481 | When a transcendent memory driver is available (such as zcache or |
482 | Xen transcendent memory), a significant I/O reduction |
483 | may be achieved. When none is available, all cleancache calls |
484 | are reduced to a single pointer-compare-against-NULL resulting |
485 | in a negligible performance hit. |
486 | |
487 | If unsure, say Y to enable cleancache |
488 | |
489 | config FRONTSWAP |
490 | bool "Enable frontswap to cache swap pages if tmem is present" |
491 | depends on SWAP |
492 | default n |
493 | help |
494 | Frontswap is so named because it can be thought of as the opposite |
495 | of a "backing" store for a swap device. The data is stored into |
496 | "transcendent memory", memory that is not directly accessible or |
497 | addressable by the kernel and is of unknown and possibly |
498 | time-varying size. When space in transcendent memory is available, |
499 | a significant swap I/O reduction may be achieved. When none is |
500 | available, all frontswap calls are reduced to a single pointer- |
501 | compare-against-NULL resulting in a negligible performance hit |
502 | and swap data is stored as normal on the matching swap device. |
503 | |
504 | If unsure, say Y to enable frontswap. |
505 | |
506 | config CMA |
507 | bool "Contiguous Memory Allocator" |
508 | depends on HAVE_MEMBLOCK && MMU |
509 | select MIGRATION |
510 | select MEMORY_ISOLATION |
511 | help |
512 | This enables the Contiguous Memory Allocator which allows other |
513 | subsystems to allocate big physically-contiguous blocks of memory. |
514 | CMA reserves a region of memory and allows only movable pages to |
515 | be allocated from it. This way, the kernel can use the memory for |
516 | pagecache and when a subsystem requests for contiguous area, the |
517 | allocated pages are migrated away to serve the contiguous request. |
518 | |
519 | If unsure, say "n". |
520 | |
521 | config CMA_DEBUG |
522 | bool "CMA debug messages (DEVELOPMENT)" |
523 | depends on DEBUG_KERNEL && CMA |
524 | help |
525 | Turns on debug messages in CMA. This produces KERN_DEBUG |
526 | messages for every CMA call as well as various messages while |
527 | processing calls such as dma_alloc_from_contiguous(). |
528 | This option does not affect warning and error messages. |
529 | |
530 | config CMA_DEBUGFS |
531 | bool "CMA debugfs interface" |
532 | depends on CMA && DEBUG_FS |
533 | help |
534 | Turns on the DebugFS interface for CMA. |
535 | |
536 | config CMA_AREAS |
537 | int "Maximum count of the CMA areas" |
538 | depends on CMA |
539 | default 7 |
540 | help |
541 | CMA allows to create CMA areas for particular purpose, mainly, |
542 | used as device private area. This parameter sets the maximum |
543 | number of CMA area in the system. |
544 | |
545 | If unsure, leave the default value "7". |
546 | |
547 | config MEM_SOFT_DIRTY |
548 | bool "Track memory changes" |
549 | depends on CHECKPOINT_RESTORE && HAVE_ARCH_SOFT_DIRTY && PROC_FS |
550 | select PROC_PAGE_MONITOR |
551 | help |
552 | This option enables memory changes tracking by introducing a |
553 | soft-dirty bit on pte-s. This bit it set when someone writes |
554 | into a page just as regular dirty bit, but unlike the latter |
555 | it can be cleared by hands. |
556 | |
557 | See Documentation/vm/soft-dirty.txt for more details. |
558 | |
559 | config ZSWAP |
560 | bool "Compressed cache for swap pages (EXPERIMENTAL)" |
561 | depends on FRONTSWAP && CRYPTO=y |
562 | select CRYPTO_LZO |
563 | select ZPOOL |
564 | default n |
565 | help |
566 | A lightweight compressed cache for swap pages. It takes |
567 | pages that are in the process of being swapped out and attempts to |
568 | compress them into a dynamically allocated RAM-based memory pool. |
569 | This can result in a significant I/O reduction on swap device and, |
570 | in the case where decompressing from RAM is faster that swap device |
571 | reads, can also improve workload performance. |
572 | |
573 | This is marked experimental because it is a new feature (as of |
574 | v3.11) that interacts heavily with memory reclaim. While these |
575 | interactions don't cause any known issues on simple memory setups, |
576 | they have not be fully explored on the large set of potential |
577 | configurations and workloads that exist. |
578 | |
579 | config ZPOOL |
580 | tristate "Common API for compressed memory storage" |
581 | default n |
582 | help |
583 | Compressed memory storage API. This allows using either zbud or |
584 | zsmalloc. |
585 | |
586 | config ZBUD |
587 | tristate "Low (Up to 2x) density storage for compressed pages" |
588 | default n |
589 | help |
590 | A special purpose allocator for storing compressed pages. |
591 | It is designed to store up to two compressed pages per physical |
592 | page. While this design limits storage density, it has simple and |
593 | deterministic reclaim properties that make it preferable to a higher |
594 | density approach when reclaim will be used. |
595 | |
596 | config Z3FOLD |
597 | tristate "Up to 3x density storage for compressed pages" |
598 | depends on ZPOOL |
599 | default n |
600 | help |
601 | A special purpose allocator for storing compressed pages. |
602 | It is designed to store up to three compressed pages per physical |
603 | page. It is a ZBUD derivative so the simplicity and determinism are |
604 | still there. |
605 | |
606 | config ZSMALLOC |
607 | tristate "Memory allocator for compressed pages" |
608 | depends on MMU |
609 | default n |
610 | help |
611 | zsmalloc is a slab-based memory allocator designed to store |
612 | compressed RAM pages. zsmalloc uses virtual memory mapping |
613 | in order to reduce fragmentation. However, this results in a |
614 | non-standard allocator interface where a handle, not a pointer, is |
615 | returned by an alloc(). This handle must be mapped in order to |
616 | access the allocated space. |
617 | |
618 | config PGTABLE_MAPPING |
619 | bool "Use page table mapping to access object in zsmalloc" |
620 | depends on ZSMALLOC |
621 | help |
622 | By default, zsmalloc uses a copy-based object mapping method to |
623 | access allocations that span two pages. However, if a particular |
624 | architecture (ex, ARM) performs VM mapping faster than copying, |
625 | then you should select this. This causes zsmalloc to use page table |
626 | mapping rather than copying for object mapping. |
627 | |
628 | You can check speed with zsmalloc benchmark: |
629 | https://github.com/spartacus06/zsmapbench |
630 | |
631 | config ZSMALLOC_STAT |
632 | bool "Export zsmalloc statistics" |
633 | depends on ZSMALLOC |
634 | select DEBUG_FS |
635 | help |
636 | This option enables code in the zsmalloc to collect various |
637 | statistics about whats happening in zsmalloc and exports that |
638 | information to userspace via debugfs. |
639 | If unsure, say N. |
640 | |
641 | config GENERIC_EARLY_IOREMAP |
642 | bool |
643 | |
644 | config MAX_STACK_SIZE_MB |
645 | int "Maximum user stack size for 32-bit processes (MB)" |
646 | default 80 |
647 | range 8 256 if METAG |
648 | range 8 2048 |
649 | depends on STACK_GROWSUP && (!64BIT || COMPAT) |
650 | help |
651 | This is the maximum stack size in Megabytes in the VM layout of 32-bit |
652 | user processes when the stack grows upwards (currently only on parisc |
653 | and metag arch). The stack will be located at the highest memory |
654 | address minus the given value, unless the RLIMIT_STACK hard limit is |
655 | changed to a smaller value in which case that is used. |
656 | |
657 | A sane initial value is 80 MB. |
658 | |
659 | # For architectures that support deferred memory initialisation |
660 | config ARCH_SUPPORTS_DEFERRED_STRUCT_PAGE_INIT |
661 | bool |
662 | |
663 | config DEFERRED_STRUCT_PAGE_INIT |
664 | bool "Defer initialisation of struct pages to kthreads" |
665 | default n |
666 | depends on ARCH_SUPPORTS_DEFERRED_STRUCT_PAGE_INIT |
667 | depends on NO_BOOTMEM && MEMORY_HOTPLUG |
668 | depends on !FLATMEM |
669 | depends on !NEED_PER_CPU_KM |
670 | help |
671 | Ordinarily all struct pages are initialised during early boot in a |
672 | single thread. On very large machines this can take a considerable |
673 | amount of time. If this option is set, large machines will bring up |
674 | a subset of memmap at boot and then initialise the rest in parallel |
675 | by starting one-off "pgdatinitX" kernel thread for each node X. This |
676 | has a potential performance impact on processes running early in the |
677 | lifetime of the system until these kthreads finish the |
678 | initialisation. |
679 | |
680 | config IDLE_PAGE_TRACKING |
681 | bool "Enable idle page tracking" |
682 | depends on SYSFS && MMU |
683 | select PAGE_EXTENSION if !64BIT |
684 | help |
685 | This feature allows to estimate the amount of user pages that have |
686 | not been touched during a given period of time. This information can |
687 | be useful to tune memory cgroup limits and/or for job placement |
688 | within a compute cluster. |
689 | |
690 | See Documentation/vm/idle_page_tracking.txt for more details. |
691 | |
692 | config ZONE_DEVICE |
693 | bool "Device memory (pmem, etc...) hotplug support" |
694 | depends on MEMORY_HOTPLUG |
695 | depends on MEMORY_HOTREMOVE |
696 | depends on SPARSEMEM_VMEMMAP |
697 | depends on X86_64 #arch_add_memory() comprehends device memory |
698 | |
699 | help |
700 | Device memory hotplug support allows for establishing pmem, |
701 | or other device driver discovered memory regions, in the |
702 | memmap. This allows pfn_to_page() lookups of otherwise |
703 | "device-physical" addresses which is needed for using a DAX |
704 | mapping in an O_DIRECT operation, among other things. |
705 | |
706 | If FS_DAX is enabled, then say Y. |
707 | |
708 | config FRAME_VECTOR |
709 | bool |
710 | |
711 | config ARCH_USES_HIGH_VMA_FLAGS |
712 | bool |
713 | config ARCH_HAS_PKEYS |
714 | bool |
715 |