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 YL |
131 | config HAVE_MEMBLOCK |
132 | boolean | |
133 | ||
7c0caeb8 TH |
134 | config HAVE_MEMBLOCK_NODE_MAP |
135 | boolean | |
136 | ||
c378ddd5 TH |
137 | config ARCH_DISCARD_MEMBLOCK |
138 | boolean | |
139 | ||
66616720 SR |
140 | config NO_BOOTMEM |
141 | boolean | |
142 | ||
ee6f509c MK |
143 | config MEMORY_ISOLATION |
144 | boolean | |
145 | ||
20b2f52b LJ |
146 | config MOVABLE_NODE |
147 | boolean "Enable to assign a node which has only movable memory" | |
148 | depends on HAVE_MEMBLOCK | |
149 | depends on NO_BOOTMEM | |
150 | depends on X86_64 | |
151 | depends on NUMA | |
c2974058 TC |
152 | default n |
153 | help | |
154 | Allow a node to have only movable memory. Pages used by the kernel, | |
155 | such as direct mapping pages cannot be migrated. So the corresponding | |
c5320926 TC |
156 | memory device cannot be hotplugged. This option allows the following |
157 | two things: | |
158 | - When the system is booting, node full of hotpluggable memory can | |
159 | be arranged to have only movable memory so that the whole node can | |
160 | be hot-removed. (need movable_node boot option specified). | |
161 | - After the system is up, the option allows users to online all the | |
162 | memory of a node as movable memory so that the whole node can be | |
163 | hot-removed. | |
164 | ||
165 | Users who don't use the memory hotplug feature are fine with this | |
166 | option on since they don't specify movable_node boot option or they | |
167 | don't online memory as movable. | |
c2974058 TC |
168 | |
169 | Say Y here if you want to hotplug a whole node. | |
170 | Say N here if you want kernel to use memory on all nodes evenly. | |
20b2f52b | 171 | |
46723bfa YI |
172 | # |
173 | # Only be set on architectures that have completely implemented memory hotplug | |
174 | # feature. If you are not sure, don't touch it. | |
175 | # | |
176 | config HAVE_BOOTMEM_INFO_NODE | |
177 | def_bool n | |
178 | ||
3947be19 DH |
179 | # eventually, we can have this option just 'select SPARSEMEM' |
180 | config MEMORY_HOTPLUG | |
181 | bool "Allow for memory hot-add" | |
ec69acbb | 182 | depends on SPARSEMEM || X86_64_ACPI_NUMA |
40b31360 | 183 | depends on ARCH_ENABLE_MEMORY_HOTPLUG |
ed84a07a | 184 | depends on (IA64 || X86 || PPC_BOOK3S_64 || SUPERH || S390) |
3947be19 | 185 | |
ec69acbb KM |
186 | config MEMORY_HOTPLUG_SPARSE |
187 | def_bool y | |
188 | depends on SPARSEMEM && MEMORY_HOTPLUG | |
189 | ||
0c0e6195 KH |
190 | config MEMORY_HOTREMOVE |
191 | bool "Allow for memory hot remove" | |
46723bfa | 192 | select MEMORY_ISOLATION |
f7e3334a | 193 | select HAVE_BOOTMEM_INFO_NODE if (X86_64 || PPC64) |
0c0e6195 KH |
194 | depends on MEMORY_HOTPLUG && ARCH_ENABLE_MEMORY_HOTREMOVE |
195 | depends on MIGRATION | |
196 | ||
e20b8cca CL |
197 | # |
198 | # If we have space for more page flags then we can enable additional | |
199 | # optimizations and functionality. | |
200 | # | |
201 | # Regular Sparsemem takes page flag bits for the sectionid if it does not | |
202 | # use a virtual memmap. Disable extended page flags for 32 bit platforms | |
203 | # that require the use of a sectionid in the page flags. | |
204 | # | |
205 | config PAGEFLAGS_EXTENDED | |
206 | def_bool y | |
a269cca9 | 207 | depends on 64BIT || SPARSEMEM_VMEMMAP || !SPARSEMEM |
e20b8cca | 208 | |
4c21e2f2 HD |
209 | # Heavily threaded applications may benefit from splitting the mm-wide |
210 | # page_table_lock, so that faults on different parts of the user address | |
211 | # space can be handled with less contention: split it at this NR_CPUS. | |
212 | # Default to 4 for wider testing, though 8 might be more appropriate. | |
213 | # ARM's adjust_pte (unused if VIPT) depends on mm-wide page_table_lock. | |
7b6ac9df | 214 | # PA-RISC 7xxx's spinlock_t would enlarge struct page from 32 to 44 bytes. |
a70caa8b | 215 | # DEBUG_SPINLOCK and DEBUG_LOCK_ALLOC spinlock_t also enlarge struct page. |
4c21e2f2 HD |
216 | # |
217 | config SPLIT_PTLOCK_CPUS | |
218 | int | |
9164550e | 219 | default "999999" if !MMU |
a70caa8b HD |
220 | default "999999" if ARM && !CPU_CACHE_VIPT |
221 | default "999999" if PARISC && !PA20 | |
4c21e2f2 | 222 | default "4" |
7cbe34cf | 223 | |
e009bb30 KS |
224 | config ARCH_ENABLE_SPLIT_PMD_PTLOCK |
225 | boolean | |
226 | ||
18468d93 RA |
227 | # |
228 | # support for memory balloon compaction | |
229 | config BALLOON_COMPACTION | |
230 | bool "Allow for balloon memory compaction/migration" | |
231 | def_bool y | |
232 | depends on COMPACTION && VIRTIO_BALLOON | |
233 | help | |
234 | Memory fragmentation introduced by ballooning might reduce | |
235 | significantly the number of 2MB contiguous memory blocks that can be | |
236 | used within a guest, thus imposing performance penalties associated | |
237 | with the reduced number of transparent huge pages that could be used | |
238 | by the guest workload. Allowing the compaction & migration for memory | |
239 | pages enlisted as being part of memory balloon devices avoids the | |
240 | scenario aforementioned and helps improving memory defragmentation. | |
241 | ||
e9e96b39 MG |
242 | # |
243 | # support for memory compaction | |
244 | config COMPACTION | |
245 | bool "Allow for memory compaction" | |
05106e6a | 246 | def_bool y |
e9e96b39 | 247 | select MIGRATION |
33a93877 | 248 | depends on MMU |
e9e96b39 MG |
249 | help |
250 | Allows the compaction of memory for the allocation of huge pages. | |
251 | ||
7cbe34cf CL |
252 | # |
253 | # support for page migration | |
254 | # | |
255 | config MIGRATION | |
b20a3503 | 256 | bool "Page migration" |
6c5240ae | 257 | def_bool y |
de32a817 | 258 | depends on (NUMA || ARCH_ENABLE_MEMORY_HOTREMOVE || COMPACTION || CMA) && MMU |
b20a3503 CL |
259 | help |
260 | Allows the migration of the physical location of pages of processes | |
e9e96b39 MG |
261 | while the virtual addresses are not changed. This is useful in |
262 | two situations. The first is on NUMA systems to put pages nearer | |
263 | to the processors accessing. The second is when allocating huge | |
264 | pages as migration can relocate pages to satisfy a huge page | |
265 | allocation instead of reclaiming. | |
6550e07f | 266 | |
600715dc JF |
267 | config PHYS_ADDR_T_64BIT |
268 | def_bool 64BIT || ARCH_PHYS_ADDR_T_64BIT | |
269 | ||
4b51d669 CL |
270 | config ZONE_DMA_FLAG |
271 | int | |
272 | default "0" if !ZONE_DMA | |
273 | default "1" | |
274 | ||
2a7326b5 | 275 | config BOUNCE |
9ca24e2e VM |
276 | bool "Enable bounce buffers" |
277 | default y | |
2a7326b5 | 278 | depends on BLOCK && MMU && (ZONE_DMA || HIGHMEM) |
9ca24e2e VM |
279 | help |
280 | Enable bounce buffers for devices that cannot access | |
281 | the full range of memory available to the CPU. Enabled | |
282 | by default when ZONE_DMA or HIGHMEM is selected, but you | |
283 | may say n to override this. | |
2a7326b5 | 284 | |
ffecfd1a DW |
285 | # On the 'tile' arch, USB OHCI needs the bounce pool since tilegx will often |
286 | # have more than 4GB of memory, but we don't currently use the IOTLB to present | |
287 | # a 32-bit address to OHCI. So we need to use a bounce pool instead. | |
288 | # | |
289 | # We also use the bounce pool to provide stable page writes for jbd. jbd | |
290 | # initiates buffer writeback without locking the page or setting PG_writeback, | |
291 | # and fixing that behavior (a second time; jbd2 doesn't have this problem) is | |
292 | # a major rework effort. Instead, use the bounce buffer to snapshot pages | |
293 | # (until jbd goes away). The only jbd user is ext3. | |
294 | config NEED_BOUNCE_POOL | |
295 | bool | |
296 | default y if (TILE && USB_OHCI_HCD) || (BLK_DEV_INTEGRITY && JBD) | |
297 | ||
6225e937 CL |
298 | config NR_QUICK |
299 | int | |
300 | depends on QUICKLIST | |
0176bd3d | 301 | default "2" if AVR32 |
6225e937 | 302 | default "1" |
f057eac0 SR |
303 | |
304 | config VIRT_TO_BUS | |
4febd95a SR |
305 | bool |
306 | help | |
307 | An architecture should select this if it implements the | |
308 | deprecated interface virt_to_bus(). All new architectures | |
309 | should probably not select this. | |
310 | ||
cddb8a5c AA |
311 | |
312 | config MMU_NOTIFIER | |
313 | bool | |
fc4d5c29 | 314 | |
f8af4da3 HD |
315 | config KSM |
316 | bool "Enable KSM for page merging" | |
317 | depends on MMU | |
318 | help | |
319 | Enable Kernel Samepage Merging: KSM periodically scans those areas | |
320 | of an application's address space that an app has advised may be | |
321 | mergeable. When it finds pages of identical content, it replaces | |
d0f209f6 | 322 | the many instances by a single page with that content, so |
f8af4da3 HD |
323 | saving memory until one or another app needs to modify the content. |
324 | Recommended for use with KVM, or with other duplicative applications. | |
c73602ad HD |
325 | See Documentation/vm/ksm.txt for more information: KSM is inactive |
326 | until a program has madvised that an area is MADV_MERGEABLE, and | |
327 | root has set /sys/kernel/mm/ksm/run to 1 (if CONFIG_SYSFS is set). | |
f8af4da3 | 328 | |
e0a94c2a CL |
329 | config DEFAULT_MMAP_MIN_ADDR |
330 | int "Low address space to protect from user allocation" | |
6e141546 | 331 | depends on MMU |
e0a94c2a CL |
332 | default 4096 |
333 | help | |
334 | This is the portion of low virtual memory which should be protected | |
335 | from userspace allocation. Keeping a user from writing to low pages | |
336 | can help reduce the impact of kernel NULL pointer bugs. | |
337 | ||
338 | For most ia64, ppc64 and x86 users with lots of address space | |
339 | a value of 65536 is reasonable and should cause no problems. | |
340 | On arm and other archs it should not be higher than 32768. | |
788084ab EP |
341 | Programs which use vm86 functionality or have some need to map |
342 | this low address space will need CAP_SYS_RAWIO or disable this | |
343 | protection by setting the value to 0. | |
e0a94c2a CL |
344 | |
345 | This value can be changed after boot using the | |
346 | /proc/sys/vm/mmap_min_addr tunable. | |
347 | ||
d949f36f LT |
348 | config ARCH_SUPPORTS_MEMORY_FAILURE |
349 | bool | |
e0a94c2a | 350 | |
6a46079c AK |
351 | config MEMORY_FAILURE |
352 | depends on MMU | |
d949f36f | 353 | depends on ARCH_SUPPORTS_MEMORY_FAILURE |
6a46079c | 354 | bool "Enable recovery from hardware memory errors" |
ee6f509c | 355 | select MEMORY_ISOLATION |
6a46079c AK |
356 | help |
357 | Enables code to recover from some memory failures on systems | |
358 | with MCA recovery. This allows a system to continue running | |
359 | even when some of its memory has uncorrected errors. This requires | |
360 | special hardware support and typically ECC memory. | |
361 | ||
cae681fc | 362 | config HWPOISON_INJECT |
413f9efb | 363 | tristate "HWPoison pages injector" |
27df5068 | 364 | depends on MEMORY_FAILURE && DEBUG_KERNEL && PROC_FS |
478c5ffc | 365 | select PROC_PAGE_MONITOR |
cae681fc | 366 | |
fc4d5c29 DH |
367 | config NOMMU_INITIAL_TRIM_EXCESS |
368 | int "Turn on mmap() excess space trimming before booting" | |
369 | depends on !MMU | |
370 | default 1 | |
371 | help | |
372 | The NOMMU mmap() frequently needs to allocate large contiguous chunks | |
373 | of memory on which to store mappings, but it can only ask the system | |
374 | allocator for chunks in 2^N*PAGE_SIZE amounts - which is frequently | |
375 | more than it requires. To deal with this, mmap() is able to trim off | |
376 | the excess and return it to the allocator. | |
377 | ||
378 | If trimming is enabled, the excess is trimmed off and returned to the | |
379 | system allocator, which can cause extra fragmentation, particularly | |
380 | if there are a lot of transient processes. | |
381 | ||
382 | If trimming is disabled, the excess is kept, but not used, which for | |
383 | long-term mappings means that the space is wasted. | |
384 | ||
385 | Trimming can be dynamically controlled through a sysctl option | |
386 | (/proc/sys/vm/nr_trim_pages) which specifies the minimum number of | |
387 | excess pages there must be before trimming should occur, or zero if | |
388 | no trimming is to occur. | |
389 | ||
390 | This option specifies the initial value of this option. The default | |
391 | of 1 says that all excess pages should be trimmed. | |
392 | ||
393 | See Documentation/nommu-mmap.txt for more information. | |
bbddff05 | 394 | |
4c76d9d1 | 395 | config TRANSPARENT_HUGEPAGE |
13ece886 | 396 | bool "Transparent Hugepage Support" |
15626062 | 397 | depends on HAVE_ARCH_TRANSPARENT_HUGEPAGE |
5d689240 | 398 | select COMPACTION |
4c76d9d1 AA |
399 | help |
400 | Transparent Hugepages allows the kernel to use huge pages and | |
401 | huge tlb transparently to the applications whenever possible. | |
402 | This feature can improve computing performance to certain | |
403 | applications by speeding up page faults during memory | |
404 | allocation, by reducing the number of tlb misses and by speeding | |
405 | up the pagetable walking. | |
406 | ||
407 | If memory constrained on embedded, you may want to say N. | |
408 | ||
13ece886 AA |
409 | choice |
410 | prompt "Transparent Hugepage Support sysfs defaults" | |
411 | depends on TRANSPARENT_HUGEPAGE | |
412 | default TRANSPARENT_HUGEPAGE_ALWAYS | |
413 | help | |
414 | Selects the sysfs defaults for Transparent Hugepage Support. | |
415 | ||
416 | config TRANSPARENT_HUGEPAGE_ALWAYS | |
417 | bool "always" | |
418 | help | |
419 | Enabling Transparent Hugepage always, can increase the | |
420 | memory footprint of applications without a guaranteed | |
421 | benefit but it will work automatically for all applications. | |
422 | ||
423 | config TRANSPARENT_HUGEPAGE_MADVISE | |
424 | bool "madvise" | |
425 | help | |
426 | Enabling Transparent Hugepage madvise, will only provide a | |
427 | performance improvement benefit to the applications using | |
428 | madvise(MADV_HUGEPAGE) but it won't risk to increase the | |
429 | memory footprint of applications without a guaranteed | |
430 | benefit. | |
431 | endchoice | |
432 | ||
5febcbe9 CY |
433 | config CROSS_MEMORY_ATTACH |
434 | bool "Cross Memory Support" | |
435 | depends on MMU | |
436 | default y | |
437 | help | |
438 | Enabling this option adds the system calls process_vm_readv and | |
439 | process_vm_writev which allow a process with the correct privileges | |
440 | to directly read from or write to to another process's address space. | |
441 | See the man page for more details. | |
442 | ||
bbddff05 TH |
443 | # |
444 | # UP and nommu archs use km based percpu allocator | |
445 | # | |
446 | config NEED_PER_CPU_KM | |
447 | depends on !SMP | |
448 | bool | |
449 | default y | |
077b1f83 DM |
450 | |
451 | config CLEANCACHE | |
452 | bool "Enable cleancache driver to cache clean pages if tmem is present" | |
453 | default n | |
454 | help | |
455 | Cleancache can be thought of as a page-granularity victim cache | |
456 | for clean pages that the kernel's pageframe replacement algorithm | |
457 | (PFRA) would like to keep around, but can't since there isn't enough | |
458 | memory. So when the PFRA "evicts" a page, it first attempts to use | |
140a1ef2 | 459 | cleancache code to put the data contained in that page into |
077b1f83 DM |
460 | "transcendent memory", memory that is not directly accessible or |
461 | addressable by the kernel and is of unknown and possibly | |
462 | time-varying size. And when a cleancache-enabled | |
463 | filesystem wishes to access a page in a file on disk, it first | |
464 | checks cleancache to see if it already contains it; if it does, | |
465 | the page is copied into the kernel and a disk access is avoided. | |
466 | When a transcendent memory driver is available (such as zcache or | |
467 | Xen transcendent memory), a significant I/O reduction | |
468 | may be achieved. When none is available, all cleancache calls | |
469 | are reduced to a single pointer-compare-against-NULL resulting | |
470 | in a negligible performance hit. | |
471 | ||
472 | If unsure, say Y to enable cleancache | |
27c6aec2 DM |
473 | |
474 | config FRONTSWAP | |
475 | bool "Enable frontswap to cache swap pages if tmem is present" | |
476 | depends on SWAP | |
477 | default n | |
478 | help | |
479 | Frontswap is so named because it can be thought of as the opposite | |
480 | of a "backing" store for a swap device. The data is stored into | |
481 | "transcendent memory", memory that is not directly accessible or | |
482 | addressable by the kernel and is of unknown and possibly | |
483 | time-varying size. When space in transcendent memory is available, | |
484 | a significant swap I/O reduction may be achieved. When none is | |
485 | available, all frontswap calls are reduced to a single pointer- | |
486 | compare-against-NULL resulting in a negligible performance hit | |
487 | and swap data is stored as normal on the matching swap device. | |
488 | ||
489 | If unsure, say Y to enable frontswap. | |
f825c736 AK |
490 | |
491 | config CMA | |
492 | bool "Contiguous Memory Allocator" | |
de32a817 | 493 | depends on HAVE_MEMBLOCK && MMU |
f825c736 AK |
494 | select MIGRATION |
495 | select MEMORY_ISOLATION | |
496 | help | |
497 | This enables the Contiguous Memory Allocator which allows other | |
498 | subsystems to allocate big physically-contiguous blocks of memory. | |
499 | CMA reserves a region of memory and allows only movable pages to | |
500 | be allocated from it. This way, the kernel can use the memory for | |
501 | pagecache and when a subsystem requests for contiguous area, the | |
502 | allocated pages are migrated away to serve the contiguous request. | |
503 | ||
504 | If unsure, say "n". | |
505 | ||
506 | config CMA_DEBUG | |
507 | bool "CMA debug messages (DEVELOPMENT)" | |
508 | depends on DEBUG_KERNEL && CMA | |
509 | help | |
510 | Turns on debug messages in CMA. This produces KERN_DEBUG | |
511 | messages for every CMA call as well as various messages while | |
512 | processing calls such as dma_alloc_from_contiguous(). | |
513 | This option does not affect warning and error messages. | |
bf550fc9 | 514 | |
4e2e2770 SJ |
515 | config ZBUD |
516 | tristate | |
517 | default n | |
518 | help | |
519 | A special purpose allocator for storing compressed pages. | |
520 | It is designed to store up to two compressed pages per physical | |
521 | page. While this design limits storage density, it has simple and | |
522 | deterministic reclaim properties that make it preferable to a higher | |
523 | density approach when reclaim will be used. | |
524 | ||
2b281117 SJ |
525 | config ZSWAP |
526 | bool "Compressed cache for swap pages (EXPERIMENTAL)" | |
527 | depends on FRONTSWAP && CRYPTO=y | |
528 | select CRYPTO_LZO | |
529 | select ZBUD | |
530 | default n | |
531 | help | |
532 | A lightweight compressed cache for swap pages. It takes | |
533 | pages that are in the process of being swapped out and attempts to | |
534 | compress them into a dynamically allocated RAM-based memory pool. | |
535 | This can result in a significant I/O reduction on swap device and, | |
536 | in the case where decompressing from RAM is faster that swap device | |
537 | reads, can also improve workload performance. | |
538 | ||
539 | This is marked experimental because it is a new feature (as of | |
540 | v3.11) that interacts heavily with memory reclaim. While these | |
541 | interactions don't cause any known issues on simple memory setups, | |
542 | they have not be fully explored on the large set of potential | |
543 | configurations and workloads that exist. | |
544 | ||
0f8975ec PE |
545 | config MEM_SOFT_DIRTY |
546 | bool "Track memory changes" | |
a844f386 | 547 | depends on CHECKPOINT_RESTORE && HAVE_ARCH_SOFT_DIRTY && PROC_FS |
0f8975ec PE |
548 | select PROC_PAGE_MONITOR |
549 | help | |
550 | This option enables memory changes tracking by introducing a | |
551 | soft-dirty bit on pte-s. This bit it set when someone writes | |
552 | into a page just as regular dirty bit, but unlike the latter | |
553 | it can be cleared by hands. | |
554 | ||
555 | See Documentation/vm/soft-dirty.txt for more details. | |
bcf1647d MK |
556 | |
557 | config ZSMALLOC | |
558 | bool "Memory allocator for compressed pages" | |
559 | depends on MMU | |
560 | default n | |
561 | help | |
562 | zsmalloc is a slab-based memory allocator designed to store | |
563 | compressed RAM pages. zsmalloc uses virtual memory mapping | |
564 | in order to reduce fragmentation. However, this results in a | |
565 | non-standard allocator interface where a handle, not a pointer, is | |
566 | returned by an alloc(). This handle must be mapped in order to | |
567 | access the allocated space. | |
568 | ||
569 | config PGTABLE_MAPPING | |
570 | bool "Use page table mapping to access object in zsmalloc" | |
571 | depends on ZSMALLOC | |
572 | help | |
573 | By default, zsmalloc uses a copy-based object mapping method to | |
574 | access allocations that span two pages. However, if a particular | |
575 | architecture (ex, ARM) performs VM mapping faster than copying, | |
576 | then you should select this. This causes zsmalloc to use page table | |
577 | mapping rather than copying for object mapping. | |
578 | ||
2216ee85 BH |
579 | You can check speed with zsmalloc benchmark: |
580 | https://github.com/spartacus06/zsmapbench |