291 lines
		
	
	
		
			9.3 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
	
	
			
		
		
	
	
			291 lines
		
	
	
		
			9.3 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.
 |