311 lines
10 KiB
Plaintext
311 lines
10 KiB
Plaintext
|
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_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.
|
||
|
|
|
||
|
|
# 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.
|
||
|
|
#
|
||
|
|
config SPLIT_PTLOCK_CPUS
|
||
|
|
int
|
||
|
|
default "4096" if ARM && !CPU_CACHE_VIPT
|
||
|
|
default "4096" if PARISC && !PA20
|
||
|
|
default "4"
|
||
|
|
|
||
|
|
#
|
||
|
|
# support for page migration
|
||
|
|
#
|
||
|
|
config MIGRATION
|
||
|
|
bool "Page migration"
|
||
|
|
def_bool y
|
||
|
|
depends on NUMA || ARCH_ENABLE_MEMORY_HOTREMOVE
|
||
|
|
help
|
||
|
|
Allows the migration of the physical location of pages of processes
|
||
|
|
while the virtual addresses are not changed. This is useful for
|
||
|
|
example on NUMA systems to put pages nearer to the processors accessing
|
||
|
|
the page.
|
||
|
|
|
||
|
|
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 SUPERH || AVR32
|
||
|
|
default "1"
|
||
|
|
|
||
|
|
config VIRT_TO_BUS
|
||
|
|
def_bool y
|
||
|
|
depends on !ARCH_NO_VIRT_TO_BUS
|
||
|
|
|
||
|
|
config HAVE_MLOCK
|
||
|
|
bool
|
||
|
|
default y if MMU=y
|
||
|
|
|
||
|
|
config HAVE_MLOCKED_PAGE_BIT
|
||
|
|
bool
|
||
|
|
default y if HAVE_MLOCK=y
|
||
|
|
|
||
|
|
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 resident 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 "Poison pages injector"
|
||
|
|
depends on MEMORY_FAILURE && DEBUG_KERNEL
|
||
|
|
|
||
|
|
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 BPA2
|
||
|
|
bool "Big Physical Area version 2"
|
||
|
|
help
|
||
|
|
Enables kernel support for reserving large areas of physical
|
||
|
|
memory at boot-time for use by certain device drivers (such as
|
||
|
|
video framegrabbers, etc.) which require it. This is backwards
|
||
|
|
compatible wit the origional "Big Physical Area" API,
|
||
|
|
but with extensions for multiple areas. It can also be configured
|
||
|
|
from the architecture specific setup code.
|
||
|
|
|
||
|
|
config BPA2_ALLOC_TRACE
|
||
|
|
bool "Trace BPA2 allocations"
|
||
|
|
depends on BPA2
|
||
|
|
depends on PROC_FS
|
||
|
|
default n
|
||
|
|
help
|
||
|
|
Enables tracing of BPA2 allocations - /proc/bpa2 will list
|
||
|
|
all the allocations together with information about a code which
|
||
|
|
called the allocator function.
|