| config SELECT_MEMORY_MODEL |
| def_bool y |
| depends on EXPERIMENTAL || ARCH_SELECT_MEMORY_MODEL |
| |
| choice |
| prompt "Memory model" |
| depends on SELECT_MEMORY_MODEL |
| default DISCONTIGMEM_MANUAL if ARCH_DISCONTIGMEM_DEFAULT |
| default SPARSEMEM_MANUAL if ARCH_SPARSEMEM_DEFAULT |
| default FLATMEM_MANUAL |
| |
| config FLATMEM_MANUAL |
| bool "Flat Memory" |
| depends on !(ARCH_DISCONTIGMEM_ENABLE || ARCH_SPARSEMEM_ENABLE) || ARCH_FLATMEM_ENABLE |
| help |
| This option allows you to change some of the ways that |
| Linux manages its memory internally. Most users will |
| only have one option here: FLATMEM. This is normal |
| and a correct option. |
| |
| Some users of more advanced features like NUMA and |
| memory hotplug may have different options here. |
| DISCONTIGMEM is an more mature, better tested system, |
| but is incompatible with memory hotplug and may suffer |
| decreased performance over SPARSEMEM. If unsure between |
| "Sparse Memory" and "Discontiguous Memory", choose |
| "Discontiguous Memory". |
| |
| If unsure, choose this option (Flat Memory) over any other. |
| |
| config DISCONTIGMEM_MANUAL |
| bool "Discontiguous Memory" |
| depends on ARCH_DISCONTIGMEM_ENABLE |
| help |
| This option provides enhanced support for discontiguous |
| memory systems, over FLATMEM. These systems have holes |
| in their physical address spaces, and this option provides |
| more efficient handling of these holes. However, the vast |
| majority of hardware has quite flat address spaces, and |
| can have degraded performance from the extra overhead that |
| this option imposes. |
| |
| Many NUMA configurations will have this as the only option. |
| |
| If unsure, choose "Flat Memory" over this option. |
| |
| config SPARSEMEM_MANUAL |
| bool "Sparse Memory" |
| depends on ARCH_SPARSEMEM_ENABLE |
| help |
| This will be the only option for some systems, including |
| memory hotplug systems. This is normal. |
| |
| For many other systems, this will be an alternative to |
| "Discontiguous Memory". This option provides some potential |
| performance benefits, along with decreased code complexity, |
| but it is newer, and more experimental. |
| |
| If unsure, choose "Discontiguous Memory" or "Flat Memory" |
| over this option. |
| |
| endchoice |
| |
| config DISCONTIGMEM |
| def_bool y |
| depends on (!SELECT_MEMORY_MODEL && ARCH_DISCONTIGMEM_ENABLE) || DISCONTIGMEM_MANUAL |
| |
| config SPARSEMEM |
| def_bool y |
| depends on (!SELECT_MEMORY_MODEL && ARCH_SPARSEMEM_ENABLE) || SPARSEMEM_MANUAL |
| |
| config FLATMEM |
| def_bool y |
| depends on (!DISCONTIGMEM && !SPARSEMEM) || FLATMEM_MANUAL |
| |
| config FLAT_NODE_MEM_MAP |
| def_bool y |
| depends on !SPARSEMEM |
| |
| # |
| # Both the NUMA code and DISCONTIGMEM use arrays of pg_data_t's |
| # to represent different areas of memory. This variable allows |
| # those dependencies to exist individually. |
| # |
| config NEED_MULTIPLE_NODES |
| def_bool y |
| depends on DISCONTIGMEM || NUMA |
| |
| config HAVE_MEMORY_PRESENT |
| def_bool y |
| depends on ARCH_HAVE_MEMORY_PRESENT || SPARSEMEM |
| |
| # |
| # SPARSEMEM_EXTREME (which is the default) does some bootmem |
| # allocations when memory_present() is called. If this cannot |
| # be done on your architecture, select this option. However, |
| # statically allocating the mem_section[] array can potentially |
| # consume vast quantities of .bss, so be careful. |
| # |
| # This option will also potentially produce smaller runtime code |
| # with gcc 3.4 and later. |
| # |
| config SPARSEMEM_STATIC |
| bool |
| |
| # |
| # Architecture platforms which require a two level mem_section in SPARSEMEM |
| # must select this option. This is usually for architecture platforms with |
| # an extremely sparse physical address space. |
| # |
| config SPARSEMEM_EXTREME |
| def_bool y |
| depends on SPARSEMEM && !SPARSEMEM_STATIC |
| |
| config SPARSEMEM_VMEMMAP_ENABLE |
| bool |
| |
| config SPARSEMEM_ALLOC_MEM_MAP_TOGETHER |
| def_bool y |
| depends on SPARSEMEM && X86_64 |
| |
| config SPARSEMEM_VMEMMAP |
| bool "Sparse Memory virtual memmap" |
| depends on SPARSEMEM && SPARSEMEM_VMEMMAP_ENABLE |
| default y |
| help |
| SPARSEMEM_VMEMMAP uses a virtually mapped memmap to optimise |
| pfn_to_page and page_to_pfn operations. This is the most |
| efficient option when sufficient kernel resources are available. |
| |
| config HAVE_MEMBLOCK |
| boolean |
| |
| # eventually, we can have this option just 'select SPARSEMEM' |
| config MEMORY_HOTPLUG |
| bool "Allow for memory hot-add" |
| depends on SPARSEMEM || X86_64_ACPI_NUMA |
| depends on HOTPLUG && ARCH_ENABLE_MEMORY_HOTPLUG |
| depends on (IA64 || X86 || PPC_BOOK3S_64 || SUPERH || S390) |
| |
| config MEMORY_HOTPLUG_SPARSE |
| def_bool y |
| depends on SPARSEMEM && MEMORY_HOTPLUG |
| |
| config MEMORY_HOTREMOVE |
| bool "Allow for memory hot remove" |
| depends on MEMORY_HOTPLUG && ARCH_ENABLE_MEMORY_HOTREMOVE |
| depends on MIGRATION |
| |
| # |
| # If we have space for more page flags then we can enable additional |
| # optimizations and functionality. |
| # |
| # Regular Sparsemem takes page flag bits for the sectionid if it does not |
| # use a virtual memmap. Disable extended page flags for 32 bit platforms |
| # that require the use of a sectionid in the page flags. |
| # |
| config PAGEFLAGS_EXTENDED |
| def_bool y |
| depends on 64BIT || SPARSEMEM_VMEMMAP || !SPARSEMEM |
| |
| # Heavily threaded applications may benefit from splitting the mm-wide |
| # page_table_lock, so that faults on different parts of the user address |
| # space can be handled with less contention: split it at this NR_CPUS. |
| # Default to 4 for wider testing, though 8 might be more appropriate. |
| # ARM's adjust_pte (unused if VIPT) depends on mm-wide page_table_lock. |
| # PA-RISC 7xxx's spinlock_t would enlarge struct page from 32 to 44 bytes. |
| # DEBUG_SPINLOCK and DEBUG_LOCK_ALLOC spinlock_t also enlarge struct page. |
| # |
| config SPLIT_PTLOCK_CPUS |
| int |
| default "999999" if ARM && !CPU_CACHE_VIPT |
| default "999999" if PARISC && !PA20 |
| default "999999" if DEBUG_SPINLOCK || DEBUG_LOCK_ALLOC |
| default "4" |
| |
| # |
| # support for memory compaction |
| config COMPACTION |
| bool "Allow for memory compaction" |
| select MIGRATION |
| depends on MMU |
| help |
| Allows the compaction of memory for the allocation of huge pages. |
| |
| # |
| # support for page migration |
| # |
| config MIGRATION |
| bool "Page migration" |
| def_bool y |
| depends on NUMA || ARCH_ENABLE_MEMORY_HOTREMOVE || COMPACTION |
| help |
| Allows the migration of the physical location of pages of processes |
| while the virtual addresses are not changed. This is useful in |
| two situations. The first is on NUMA systems to put pages nearer |
| to the processors accessing. The second is when allocating huge |
| pages as migration can relocate pages to satisfy a huge page |
| allocation instead of reclaiming. |
| |
| config PHYS_ADDR_T_64BIT |
| def_bool 64BIT || ARCH_PHYS_ADDR_T_64BIT |
| |
| config ZONE_DMA_FLAG |
| int |
| default "0" if !ZONE_DMA |
| default "1" |
| |
| config BOUNCE |
| def_bool y |
| depends on BLOCK && MMU && (ZONE_DMA || HIGHMEM) |
| |
| config NR_QUICK |
| int |
| depends on QUICKLIST |
| default "2" if AVR32 |
| default "1" |
| |
| config VIRT_TO_BUS |
| def_bool y |
| depends on !ARCH_NO_VIRT_TO_BUS |
| |
| config MMU_NOTIFIER |
| bool |
| |
| config KSM |
| bool "Enable KSM for page merging" |
| depends on MMU |
| help |
| Enable Kernel Samepage Merging: KSM periodically scans those areas |
| of an application's address space that an app has advised may be |
| mergeable. When it finds pages of identical content, it replaces |
| the many instances by a single page with that content, so |
| saving memory until one or another app needs to modify the content. |
| Recommended for use with KVM, or with other duplicative applications. |
| See Documentation/vm/ksm.txt for more information: KSM is inactive |
| until a program has madvised that an area is MADV_MERGEABLE, and |
| root has set /sys/kernel/mm/ksm/run to 1 (if CONFIG_SYSFS is set). |
| |
| config DEFAULT_MMAP_MIN_ADDR |
| int "Low address space to protect from user allocation" |
| depends on MMU |
| default 4096 |
| help |
| This is the portion of low virtual memory which should be protected |
| from userspace allocation. Keeping a user from writing to low pages |
| can help reduce the impact of kernel NULL pointer bugs. |
| |
| For most ia64, ppc64 and x86 users with lots of address space |
| a value of 65536 is reasonable and should cause no problems. |
| On arm and other archs it should not be higher than 32768. |
| Programs which use vm86 functionality or have some need to map |
| this low address space will need CAP_SYS_RAWIO or disable this |
| protection by setting the value to 0. |
| |
| This value can be changed after boot using the |
| /proc/sys/vm/mmap_min_addr tunable. |
| |
| config ARCH_SUPPORTS_MEMORY_FAILURE |
| bool |
| |
| config MEMORY_FAILURE |
| depends on MMU |
| depends on ARCH_SUPPORTS_MEMORY_FAILURE |
| bool "Enable recovery from hardware memory errors" |
| help |
| Enables code to recover from some memory failures on systems |
| with MCA recovery. This allows a system to continue running |
| even when some of its memory has uncorrected errors. This requires |
| special hardware support and typically ECC memory. |
| |
| config HWPOISON_INJECT |
| tristate "HWPoison pages injector" |
| depends on MEMORY_FAILURE && DEBUG_KERNEL && PROC_FS |
| select PROC_PAGE_MONITOR |
| |
| config NOMMU_INITIAL_TRIM_EXCESS |
| int "Turn on mmap() excess space trimming before booting" |
| depends on !MMU |
| default 1 |
| help |
| The NOMMU mmap() frequently needs to allocate large contiguous chunks |
| of memory on which to store mappings, but it can only ask the system |
| allocator for chunks in 2^N*PAGE_SIZE amounts - which is frequently |
| more than it requires. To deal with this, mmap() is able to trim off |
| the excess and return it to the allocator. |
| |
| If trimming is enabled, the excess is trimmed off and returned to the |
| system allocator, which can cause extra fragmentation, particularly |
| if there are a lot of transient processes. |
| |
| If trimming is disabled, the excess is kept, but not used, which for |
| long-term mappings means that the space is wasted. |
| |
| Trimming can be dynamically controlled through a sysctl option |
| (/proc/sys/vm/nr_trim_pages) which specifies the minimum number of |
| excess pages there must be before trimming should occur, or zero if |
| no trimming is to occur. |
| |
| This option specifies the initial value of this option. The default |
| of 1 says that all excess pages should be trimmed. |
| |
| See Documentation/nommu-mmap.txt for more information. |
| |
| config TRANSPARENT_HUGEPAGE |
| bool "Transparent Hugepage Support" |
| depends on X86 && MMU |
| select COMPACTION |
| help |
| Transparent Hugepages allows the kernel to use huge pages and |
| huge tlb transparently to the applications whenever possible. |
| This feature can improve computing performance to certain |
| applications by speeding up page faults during memory |
| allocation, by reducing the number of tlb misses and by speeding |
| up the pagetable walking. |
| |
| If memory constrained on embedded, you may want to say N. |
| |
| choice |
| prompt "Transparent Hugepage Support sysfs defaults" |
| depends on TRANSPARENT_HUGEPAGE |
| default TRANSPARENT_HUGEPAGE_ALWAYS |
| help |
| Selects the sysfs defaults for Transparent Hugepage Support. |
| |
| config TRANSPARENT_HUGEPAGE_ALWAYS |
| bool "always" |
| help |
| Enabling Transparent Hugepage always, can increase the |
| memory footprint of applications without a guaranteed |
| benefit but it will work automatically for all applications. |
| |
| config TRANSPARENT_HUGEPAGE_MADVISE |
| bool "madvise" |
| help |
| Enabling Transparent Hugepage madvise, will only provide a |
| performance improvement benefit to the applications using |
| madvise(MADV_HUGEPAGE) but it won't risk to increase the |
| memory footprint of applications without a guaranteed |
| benefit. |
| endchoice |
| |
| # |
| # UP and nommu archs use km based percpu allocator |
| # |
| config NEED_PER_CPU_KM |
| depends on !SMP |
| bool |
| default y |
| |
| config CLEANCACHE |
| bool "Enable cleancache driver to cache clean pages if tmem is present" |
| default n |
| help |
| Cleancache can be thought of as a page-granularity victim cache |
| for clean pages that the kernel's pageframe replacement algorithm |
| (PFRA) would like to keep around, but can't since there isn't enough |
| memory. So when the PFRA "evicts" a page, it first attempts to use |
| cleancacne code to put the data contained in that page into |
| "transcendent memory", memory that is not directly accessible or |
| addressable by the kernel and is of unknown and possibly |
| time-varying size. And when a cleancache-enabled |
| filesystem wishes to access a page in a file on disk, it first |
| checks cleancache to see if it already contains it; if it does, |
| the page is copied into the kernel and a disk access is avoided. |
| When a transcendent memory driver is available (such as zcache or |
| Xen transcendent memory), a significant I/O reduction |
| may be achieved. When none is available, all cleancache calls |
| are reduced to a single pointer-compare-against-NULL resulting |
| in a negligible performance hit. |
| |
| If unsure, say Y to enable cleancache |
