tmpfs: copy truncate_inode_pages_range
[linux-2.6.git] / mm / Kconfig
index 5127441..f2f1ca1 100644 (file)
@@ -6,21 +6,30 @@ 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_FLATMEM_ENABLE
+       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.
 
-         If unsure, choose this option over any other.
+         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 "Discontigious Memory"
+       bool "Discontiguous Memory"
        depends on ARCH_DISCONTIGMEM_ENABLE
        help
          This option provides enhanced support for discontiguous
@@ -28,22 +37,45 @@ config DISCONTIGMEM_MANUAL
          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 extra overhead that
+         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 || FLATMEM_MANUAL
+       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
@@ -56,4 +88,285 @@ config NEED_MULTIPLE_NODES
 
 config HAVE_MEMORY_PRESENT
        def_bool y
-       depends on ARCH_HAVE_MEMORY_PRESENT
+       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
+         cleancache 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