Re: [PATCH 2/7] order memory debugging Kconfig options

[Paul E. McKenney]

On Mon, Jul 01, 2013 at 01:04:43PM -0700, Dave Hansen wrote:
> 
> From: Dave Hansen <dave@xxxxxxxxxxxxxxxxxx>
> 
> Original posting:
> 
> 	http://lkml.kernel.org/r/20121214184203.37E6C724@xxxxxxxxxxxxxxxxxxxxxx
> 
> There are a *LOT* of memory debugging options.  They are just scattered
> all over the "Kernel Hacking" menu.  Sure, "memory debugging" is a very
> vague term and it's going to be hard to make absolute rules about what
> goes in here, but this has to be better than what we had before.
> 
> This does, however, leave out the architecture-specific memory
> debugging options (like x86's DEBUG_SET_MODULE_RONX).  There would need
> to be some substantial changes to move those in here.  Kconfig can not
> easily mix arch-specific and generic options together: it really
> requires a file per-architecture, and I think having an
> arch/foo/Kconfig.debug-memory might be taking things a bit too far
> 
> Signed-off-by: Dave Hansen <dave@xxxxxxxxxxxxxxxxxx>
> Signed-off-by: Dave Hansen <dave.hansen@xxxxxxxxxxxxxxx>

For the RCU-related options:

Acked-by: Paul E. McKenney <paulmck@xxxxxxxxxxxxxxxxxx>

> ---
> 
>  linux.git-davehans/lib/Kconfig.debug |  685 +++++++++++++++++------------------
>  1 file changed, 345 insertions(+), 340 deletions(-)
> 
> diff -puN lib/Kconfig.debug~order-memory-debugging-options lib/Kconfig.debug
> --- linux.git/lib/Kconfig.debug~order-memory-debugging-options	2013-07-01 12:53:20.740497368 -0700
> +++ linux.git-davehans/lib/Kconfig.debug	2013-07-01 12:53:20.745497590 -0700
> @@ -162,6 +162,283 @@ config DEBUG_KERNEL
>  	  Say Y here if you are developing drivers or trying to debug and
>  	  identify kernel problems.
> 
> +menu "Memory Debugging"
> +
> +source mm/Kconfig.debug
> +
> +config DEBUG_OBJECTS
> +	bool "Debug object operations"
> +	depends on DEBUG_KERNEL
> +	help
> +	  If you say Y here, additional code will be inserted into the
> +	  kernel to track the life time of various objects and validate
> +	  the operations on those objects.
> +
> +config DEBUG_OBJECTS_SELFTEST
> +	bool "Debug objects selftest"
> +	depends on DEBUG_OBJECTS
> +	help
> +	  This enables the selftest of the object debug code.
> +
> +config DEBUG_OBJECTS_FREE
> +	bool "Debug objects in freed memory"
> +	depends on DEBUG_OBJECTS
> +	help
> +	  This enables checks whether a k/v free operation frees an area
> +	  which contains an object which has not been deactivated
> +	  properly. This can make kmalloc/kfree-intensive workloads
> +	  much slower.
> +
> +config DEBUG_OBJECTS_TIMERS
> +	bool "Debug timer objects"
> +	depends on DEBUG_OBJECTS
> +	help
> +	  If you say Y here, additional code will be inserted into the
> +	  timer routines to track the life time of timer objects and
> +	  validate the timer operations.
> +
> +config DEBUG_OBJECTS_WORK
> +	bool "Debug work objects"
> +	depends on DEBUG_OBJECTS
> +	help
> +	  If you say Y here, additional code will be inserted into the
> +	  work queue routines to track the life time of work objects and
> +	  validate the work operations.
> +
> +config DEBUG_OBJECTS_RCU_HEAD
> +	bool "Debug RCU callbacks objects"
> +	depends on DEBUG_OBJECTS
> +	help
> +	  Enable this to turn on debugging of RCU list heads (call_rcu() usage).
> +
> +config DEBUG_OBJECTS_PERCPU_COUNTER
> +	bool "Debug percpu counter objects"
> +	depends on DEBUG_OBJECTS
> +	help
> +	  If you say Y here, additional code will be inserted into the
> +	  percpu counter routines to track the life time of percpu counter
> +	  objects and validate the percpu counter operations.
> +
> +config DEBUG_OBJECTS_ENABLE_DEFAULT
> +	int "debug_objects bootup default value (0-1)"
> +        range 0 1
> +        default "1"
> +        depends on DEBUG_OBJECTS
> +        help
> +          Debug objects boot parameter default value
> +
> +config DEBUG_SLAB
> +	bool "Debug slab memory allocations"
> +	depends on DEBUG_KERNEL && SLAB && !KMEMCHECK
> +	help
> +	  Say Y here to have the kernel do limited verification on memory
> +	  allocation as well as poisoning memory on free to catch use of freed
> +	  memory. This can make kmalloc/kfree-intensive workloads much slower.
> +
> +config DEBUG_SLAB_LEAK
> +	bool "Memory leak debugging"
> +	depends on DEBUG_SLAB
> +
> +config SLUB_DEBUG_ON
> +	bool "SLUB debugging on by default"
> +	depends on SLUB && SLUB_DEBUG && !KMEMCHECK
> +	default n
> +	help
> +	  Boot with debugging on by default. SLUB boots by default with
> +	  the runtime debug capabilities switched off. Enabling this is
> +	  equivalent to specifying the "slub_debug" parameter on boot.
> +	  There is no support for more fine grained debug control like
> +	  possible with slub_debug=xxx. SLUB debugging may be switched
> +	  off in a kernel built with CONFIG_SLUB_DEBUG_ON by specifying
> +	  "slub_debug=-".
> +
> +config SLUB_STATS
> +	default n
> +	bool "Enable SLUB performance statistics"
> +	depends on SLUB && SYSFS
> +	help
> +	  SLUB statistics are useful to debug SLUBs allocation behavior in
> +	  order find ways to optimize the allocator. This should never be
> +	  enabled for production use since keeping statistics slows down
> +	  the allocator by a few percentage points. The slabinfo command
> +	  supports the determination of the most active slabs to figure
> +	  out which slabs are relevant to a particular load.
> +	  Try running: slabinfo -DA
> +
> +config HAVE_DEBUG_KMEMLEAK
> +	bool
> +
> +config DEBUG_KMEMLEAK
> +	bool "Kernel memory leak detector"
> +	depends on DEBUG_KERNEL && HAVE_DEBUG_KMEMLEAK
> +	select DEBUG_FS
> +	select STACKTRACE if STACKTRACE_SUPPORT
> +	select KALLSYMS
> +	select CRC32
> +	help
> +	  Say Y here if you want to enable the memory leak
> +	  detector. The memory allocation/freeing is traced in a way
> +	  similar to the Boehm's conservative garbage collector, the
> +	  difference being that the orphan objects are not freed but
> +	  only shown in /sys/kernel/debug/kmemleak. Enabling this
> +	  feature will introduce an overhead to memory
> +	  allocations. See Documentation/kmemleak.txt for more
> +	  details.
> +
> +	  Enabling DEBUG_SLAB or SLUB_DEBUG may increase the chances
> +	  of finding leaks due to the slab objects poisoning.
> +
> +	  In order to access the kmemleak file, debugfs needs to be
> +	  mounted (usually at /sys/kernel/debug).
> +
> +config DEBUG_KMEMLEAK_EARLY_LOG_SIZE
> +	int "Maximum kmemleak early log entries"
> +	depends on DEBUG_KMEMLEAK
> +	range 200 40000
> +	default 400
> +	help
> +	  Kmemleak must track all the memory allocations to avoid
> +	  reporting false positives. Since memory may be allocated or
> +	  freed before kmemleak is initialised, an early log buffer is
> +	  used to store these actions. If kmemleak reports "early log
> +	  buffer exceeded", please increase this value.
> +
> +config DEBUG_KMEMLEAK_TEST
> +	tristate "Simple test for the kernel memory leak detector"
> +	depends on DEBUG_KMEMLEAK && m
> +	help
> +	  This option enables a module that explicitly leaks memory.
> +
> +	  If unsure, say N.
> +
> +config DEBUG_KMEMLEAK_DEFAULT_OFF
> +	bool "Default kmemleak to off"
> +	depends on DEBUG_KMEMLEAK
> +	help
> +	  Say Y here to disable kmemleak by default. It can then be enabled
> +	  on the command line via kmemleak=on.
> +
> +config DEBUG_STACK_USAGE
> +	bool "Stack utilization instrumentation"
> +	depends on DEBUG_KERNEL && !IA64 && !PARISC && !METAG
> +	help
> +	  Enables the display of the minimum amount of free stack which each
> +	  task has ever had available in the sysrq-T and sysrq-P debug output.
> +
> +	  This option will slow down process creation somewhat.
> +
> +config DEBUG_VM
> +	bool "Debug VM"
> +	depends on DEBUG_KERNEL
> +	help
> +	  Enable this to turn on extended checks in the virtual-memory system
> +          that may impact performance.
> +
> +	  If unsure, say N.
> +
> +config DEBUG_VM_RB
> +	bool "Debug VM red-black trees"
> +	depends on DEBUG_VM
> +	help
> +	  Enable this to turn on more extended checks in the virtual-memory
> +	  system that may impact performance.
> +
> +	  If unsure, say N.
> +
> +config DEBUG_VIRTUAL
> +	bool "Debug VM translations"
> +	depends on DEBUG_KERNEL && X86
> +	help
> +	  Enable some costly sanity checks in virtual to page code. This can
> +	  catch mistakes with virt_to_page() and friends.
> +
> +	  If unsure, say N.
> +
> +config DEBUG_NOMMU_REGIONS
> +	bool "Debug the global anon/private NOMMU mapping region tree"
> +	depends on DEBUG_KERNEL && !MMU
> +	help
> +	  This option causes the global tree of anonymous and private mapping
> +	  regions to be regularly checked for invalid topology.
> +
> +config DEBUG_MEMORY_INIT
> +	bool "Debug memory initialisation" if EXPERT
> +	default !EXPERT
> +	help
> +	  Enable this for additional checks during memory initialisation.
> +	  The sanity checks verify aspects of the VM such as the memory model
> +	  and other information provided by the architecture. Verbose
> +	  information will be printed at KERN_DEBUG loglevel depending
> +	  on the mminit_loglevel= command-line option.
> +
> +	  If unsure, say Y
> +
> +config MEMORY_NOTIFIER_ERROR_INJECT
> +	tristate "Memory hotplug notifier error injection module"
> +	depends on MEMORY_HOTPLUG_SPARSE && NOTIFIER_ERROR_INJECTION
> +	help
> +	  This option provides the ability to inject artificial errors to
> +	  memory hotplug notifier chain callbacks.  It is controlled through
> +	  debugfs interface under /sys/kernel/debug/notifier-error-inject/memory
> +
> +	  If the notifier call chain should be failed with some events
> +	  notified, write the error code to "actions/<notifier event>/error".
> +
> +	  Example: Inject memory hotplug offline error (-12 == -ENOMEM)
> +
> +	  # cd /sys/kernel/debug/notifier-error-inject/memory
> +	  # echo -12 > actions/MEM_GOING_OFFLINE/error
> +	  # echo offline > /sys/devices/system/memory/memoryXXX/state
> +	  bash: echo: write error: Cannot allocate memory
> +
> +	  To compile this code as a module, choose M here: the module will
> +	  be called memory-notifier-error-inject.
> +
> +	  If unsure, say N.
> +
> +config DEBUG_PER_CPU_MAPS
> +	bool "Debug access to per_cpu maps"
> +	depends on DEBUG_KERNEL
> +	depends on SMP
> +	help
> +	  Say Y to verify that the per_cpu map being accessed has
> +	  been set up. This adds a fair amount of code to kernel memory
> +	  and decreases performance.
> +
> +	  Say N if unsure.
> +
> +config DEBUG_HIGHMEM
> +	bool "Highmem debugging"
> +	depends on DEBUG_KERNEL && HIGHMEM
> +	help
> +	  This options enables addition error checking for high memory systems.
> +	  Disable for production systems.
> +
> +config HAVE_DEBUG_STACKOVERFLOW
> +	bool
> +
> +config DEBUG_STACKOVERFLOW
> +	bool "Check for stack overflows"
> +	depends on DEBUG_KERNEL && HAVE_DEBUG_STACKOVERFLOW
> +	---help---
> +	  Say Y here if you want to check for overflows of kernel, IRQ
> +	  and exception stacks (if your archicture uses them). This
> +	  option will show detailed messages if free stack space drops
> +	  below a certain limit.
> +
> +	  These kinds of bugs usually occur when call-chains in the
> +	  kernel get too deep, especially when interrupts are
> +	  involved.
> +
> +	  Use this in cases where you see apparently random memory
> +	  corruption, especially if it appears in 'struct thread_info'
> +
> +	  If in doubt, say "N".
> +
> +source "lib/Kconfig.kmemcheck"
> +
> +endmenu # "Memory Debugging"
> +
>  config DEBUG_SHIRQ
>  	bool "Debug shared IRQ handlers"
>  	depends on DEBUG_KERNEL && GENERIC_HARDIRQS
> @@ -266,241 +543,89 @@ config DETECT_HUNG_TASK
>  	depends on DEBUG_KERNEL
>  	default LOCKUP_DETECTOR
>  	help
> -	  Say Y here to enable the kernel to detect "hung tasks",
> -	  which are bugs that cause the task to be stuck in
> -	  uninterruptible "D" state indefinitiley.
> -
> -	  When a hung task is detected, the kernel will print the
> -	  current stack trace (which you should report), but the
> -	  task will stay in uninterruptible state. If lockdep is
> -	  enabled then all held locks will also be reported. This
> -	  feature has negligible overhead.
> -
> -config DEFAULT_HUNG_TASK_TIMEOUT
> -	int "Default timeout for hung task detection (in seconds)"
> -	depends on DETECT_HUNG_TASK
> -	default 120
> -	help
> -	  This option controls the default timeout (in seconds) used
> -	  to determine when a task has become non-responsive and should
> -	  be considered hung.
> -
> -	  It can be adjusted at runtime via the kernel.hung_task_timeout_secs
> -	  sysctl or by writing a value to
> -	  /proc/sys/kernel/hung_task_timeout_secs.
> -
> -	  A timeout of 0 disables the check.  The default is two minutes.
> -	  Keeping the default should be fine in most cases.
> -
> -config BOOTPARAM_HUNG_TASK_PANIC
> -	bool "Panic (Reboot) On Hung Tasks"
> -	depends on DETECT_HUNG_TASK
> -	help
> -	  Say Y here to enable the kernel to panic on "hung tasks",
> -	  which are bugs that cause the kernel to leave a task stuck
> -	  in uninterruptible "D" state.
> -
> -	  The panic can be used in combination with panic_timeout,
> -	  to cause the system to reboot automatically after a
> -	  hung task has been detected. This feature is useful for
> -	  high-availability systems that have uptime guarantees and
> -	  where a hung tasks must be resolved ASAP.
> -
> -	  Say N if unsure.
> -
> -config BOOTPARAM_HUNG_TASK_PANIC_VALUE
> -	int
> -	depends on DETECT_HUNG_TASK
> -	range 0 1
> -	default 0 if !BOOTPARAM_HUNG_TASK_PANIC
> -	default 1 if BOOTPARAM_HUNG_TASK_PANIC
> -
> -config SCHED_DEBUG
> -	bool "Collect scheduler debugging info"
> -	depends on DEBUG_KERNEL && PROC_FS
> -	default y
> -	help
> -	  If you say Y here, the /proc/sched_debug file will be provided
> -	  that can help debug the scheduler. The runtime overhead of this
> -	  option is minimal.
> -
> -config SCHEDSTATS
> -	bool "Collect scheduler statistics"
> -	depends on DEBUG_KERNEL && PROC_FS
> -	help
> -	  If you say Y here, additional code will be inserted into the
> -	  scheduler and related routines to collect statistics about
> -	  scheduler behavior and provide them in /proc/schedstat.  These
> -	  stats may be useful for both tuning and debugging the scheduler
> -	  If you aren't debugging the scheduler or trying to tune a specific
> -	  application, you can say N to avoid the very slight overhead
> -	  this adds.
> -
> -config TIMER_STATS
> -	bool "Collect kernel timers statistics"
> -	depends on DEBUG_KERNEL && PROC_FS
> -	help
> -	  If you say Y here, additional code will be inserted into the
> -	  timer routines to collect statistics about kernel timers being
> -	  reprogrammed. The statistics can be read from /proc/timer_stats.
> -	  The statistics collection is started by writing 1 to /proc/timer_stats,
> -	  writing 0 stops it. This feature is useful to collect information
> -	  about timer usage patterns in kernel and userspace. This feature
> -	  is lightweight if enabled in the kernel config but not activated
> -	  (it defaults to deactivated on bootup and will only be activated
> -	  if some application like powertop activates it explicitly).
> -
> -config DEBUG_OBJECTS
> -	bool "Debug object operations"
> -	depends on DEBUG_KERNEL
> -	help
> -	  If you say Y here, additional code will be inserted into the
> -	  kernel to track the life time of various objects and validate
> -	  the operations on those objects.
> -
> -config DEBUG_OBJECTS_SELFTEST
> -	bool "Debug objects selftest"
> -	depends on DEBUG_OBJECTS
> -	help
> -	  This enables the selftest of the object debug code.
> -
> -config DEBUG_OBJECTS_FREE
> -	bool "Debug objects in freed memory"
> -	depends on DEBUG_OBJECTS
> -	help
> -	  This enables checks whether a k/v free operation frees an area
> -	  which contains an object which has not been deactivated
> -	  properly. This can make kmalloc/kfree-intensive workloads
> -	  much slower.
> -
> -config DEBUG_OBJECTS_TIMERS
> -	bool "Debug timer objects"
> -	depends on DEBUG_OBJECTS
> -	help
> -	  If you say Y here, additional code will be inserted into the
> -	  timer routines to track the life time of timer objects and
> -	  validate the timer operations.
> -
> -config DEBUG_OBJECTS_WORK
> -	bool "Debug work objects"
> -	depends on DEBUG_OBJECTS
> -	help
> -	  If you say Y here, additional code will be inserted into the
> -	  work queue routines to track the life time of work objects and
> -	  validate the work operations.
> -
> -config DEBUG_OBJECTS_RCU_HEAD
> -	bool "Debug RCU callbacks objects"
> -	depends on DEBUG_OBJECTS
> -	help
> -	  Enable this to turn on debugging of RCU list heads (call_rcu() usage).
> -
> -config DEBUG_OBJECTS_PERCPU_COUNTER
> -	bool "Debug percpu counter objects"
> -	depends on DEBUG_OBJECTS
> -	help
> -	  If you say Y here, additional code will be inserted into the
> -	  percpu counter routines to track the life time of percpu counter
> -	  objects and validate the percpu counter operations.
> -
> -config DEBUG_OBJECTS_ENABLE_DEFAULT
> -	int "debug_objects bootup default value (0-1)"
> -        range 0 1
> -        default "1"
> -        depends on DEBUG_OBJECTS
> -        help
> -          Debug objects boot parameter default value
> -
> -config DEBUG_SLAB
> -	bool "Debug slab memory allocations"
> -	depends on DEBUG_KERNEL && SLAB && !KMEMCHECK
> -	help
> -	  Say Y here to have the kernel do limited verification on memory
> -	  allocation as well as poisoning memory on free to catch use of freed
> -	  memory. This can make kmalloc/kfree-intensive workloads much slower.
> +	  Say Y here to enable the kernel to detect "hung tasks",
> +	  which are bugs that cause the task to be stuck in
> +	  uninterruptible "D" state indefinitiley.
> 
> -config DEBUG_SLAB_LEAK
> -	bool "Memory leak debugging"
> -	depends on DEBUG_SLAB
> +	  When a hung task is detected, the kernel will print the
> +	  current stack trace (which you should report), but the
> +	  task will stay in uninterruptible state. If lockdep is
> +	  enabled then all held locks will also be reported. This
> +	  feature has negligible overhead.
> 
> -config SLUB_DEBUG_ON
> -	bool "SLUB debugging on by default"
> -	depends on SLUB && SLUB_DEBUG && !KMEMCHECK
> -	default n
> +config DEFAULT_HUNG_TASK_TIMEOUT
> +	int "Default timeout for hung task detection (in seconds)"
> +	depends on DETECT_HUNG_TASK
> +	default 120
>  	help
> -	  Boot with debugging on by default. SLUB boots by default with
> -	  the runtime debug capabilities switched off. Enabling this is
> -	  equivalent to specifying the "slub_debug" parameter on boot.
> -	  There is no support for more fine grained debug control like
> -	  possible with slub_debug=xxx. SLUB debugging may be switched
> -	  off in a kernel built with CONFIG_SLUB_DEBUG_ON by specifying
> -	  "slub_debug=-".
> +	  This option controls the default timeout (in seconds) used
> +	  to determine when a task has become non-responsive and should
> +	  be considered hung.
> 
> -config SLUB_STATS
> -	default n
> -	bool "Enable SLUB performance statistics"
> -	depends on SLUB && SYSFS
> -	help
> -	  SLUB statistics are useful to debug SLUBs allocation behavior in
> -	  order find ways to optimize the allocator. This should never be
> -	  enabled for production use since keeping statistics slows down
> -	  the allocator by a few percentage points. The slabinfo command
> -	  supports the determination of the most active slabs to figure
> -	  out which slabs are relevant to a particular load.
> -	  Try running: slabinfo -DA
> +	  It can be adjusted at runtime via the kernel.hung_task_timeout_secs
> +	  sysctl or by writing a value to
> +	  /proc/sys/kernel/hung_task_timeout_secs.
> 
> -config HAVE_DEBUG_KMEMLEAK
> -	bool
> +	  A timeout of 0 disables the check.  The default is two minutes.
> +	  Keeping the default should be fine in most cases.
> 
> -config DEBUG_KMEMLEAK
> -	bool "Kernel memory leak detector"
> -	depends on DEBUG_KERNEL && HAVE_DEBUG_KMEMLEAK
> -	select DEBUG_FS
> -	select STACKTRACE if STACKTRACE_SUPPORT
> -	select KALLSYMS
> -	select CRC32
> +config BOOTPARAM_HUNG_TASK_PANIC
> +	bool "Panic (Reboot) On Hung Tasks"
> +	depends on DETECT_HUNG_TASK
>  	help
> -	  Say Y here if you want to enable the memory leak
> -	  detector. The memory allocation/freeing is traced in a way
> -	  similar to the Boehm's conservative garbage collector, the
> -	  difference being that the orphan objects are not freed but
> -	  only shown in /sys/kernel/debug/kmemleak. Enabling this
> -	  feature will introduce an overhead to memory
> -	  allocations. See Documentation/kmemleak.txt for more
> -	  details.
> +	  Say Y here to enable the kernel to panic on "hung tasks",
> +	  which are bugs that cause the kernel to leave a task stuck
> +	  in uninterruptible "D" state.
> 
> -	  Enabling DEBUG_SLAB or SLUB_DEBUG may increase the chances
> -	  of finding leaks due to the slab objects poisoning.
> +	  The panic can be used in combination with panic_timeout,
> +	  to cause the system to reboot automatically after a
> +	  hung task has been detected. This feature is useful for
> +	  high-availability systems that have uptime guarantees and
> +	  where a hung tasks must be resolved ASAP.
> 
> -	  In order to access the kmemleak file, debugfs needs to be
> -	  mounted (usually at /sys/kernel/debug).
> +	  Say N if unsure.
> 
> -config DEBUG_KMEMLEAK_EARLY_LOG_SIZE
> -	int "Maximum kmemleak early log entries"
> -	depends on DEBUG_KMEMLEAK
> -	range 200 40000
> -	default 400
> -	help
> -	  Kmemleak must track all the memory allocations to avoid
> -	  reporting false positives. Since memory may be allocated or
> -	  freed before kmemleak is initialised, an early log buffer is
> -	  used to store these actions. If kmemleak reports "early log
> -	  buffer exceeded", please increase this value.
> +config BOOTPARAM_HUNG_TASK_PANIC_VALUE
> +	int
> +	depends on DETECT_HUNG_TASK
> +	range 0 1
> +	default 0 if !BOOTPARAM_HUNG_TASK_PANIC
> +	default 1 if BOOTPARAM_HUNG_TASK_PANIC
> 
> -config DEBUG_KMEMLEAK_TEST
> -	tristate "Simple test for the kernel memory leak detector"
> -	depends on DEBUG_KMEMLEAK && m
> +config SCHED_DEBUG
> +	bool "Collect scheduler debugging info"
> +	depends on DEBUG_KERNEL && PROC_FS
> +	default y
>  	help
> -	  This option enables a module that explicitly leaks memory.
> +	  If you say Y here, the /proc/sched_debug file will be provided
> +	  that can help debug the scheduler. The runtime overhead of this
> +	  option is minimal.
> 
> -	  If unsure, say N.
> +config SCHEDSTATS
> +	bool "Collect scheduler statistics"
> +	depends on DEBUG_KERNEL && PROC_FS
> +	help
> +	  If you say Y here, additional code will be inserted into the
> +	  scheduler and related routines to collect statistics about
> +	  scheduler behavior and provide them in /proc/schedstat.  These
> +	  stats may be useful for both tuning and debugging the scheduler
> +	  If you aren't debugging the scheduler or trying to tune a specific
> +	  application, you can say N to avoid the very slight overhead
> +	  this adds.
> 
> -config DEBUG_KMEMLEAK_DEFAULT_OFF
> -	bool "Default kmemleak to off"
> -	depends on DEBUG_KMEMLEAK
> +config TIMER_STATS
> +	bool "Collect kernel timers statistics"
> +	depends on DEBUG_KERNEL && PROC_FS
>  	help
> -	  Say Y here to disable kmemleak by default. It can then be enabled
> -	  on the command line via kmemleak=on.
> +	  If you say Y here, additional code will be inserted into the
> +	  timer routines to collect statistics about kernel timers being
> +	  reprogrammed. The statistics can be read from /proc/timer_stats.
> +	  The statistics collection is started by writing 1 to /proc/timer_stats,
> +	  writing 0 stops it. This feature is useful to collect information
> +	  about timer usage patterns in kernel and userspace. This feature
> +	  is lightweight if enabled in the kernel config but not activated
> +	  (it defaults to deactivated on bootup and will only be activated
> +	  if some application like powertop activates it explicitly).
> 
>  config DEBUG_PREEMPT
>  	bool "Debug preemptible kernel"
> @@ -672,15 +797,6 @@ config STACKTRACE
>  	bool
>  	depends on STACKTRACE_SUPPORT
> 
> -config DEBUG_STACK_USAGE
> -	bool "Stack utilization instrumentation"
> -	depends on DEBUG_KERNEL && !IA64 && !PARISC && !METAG
> -	help
> -	  Enables the display of the minimum amount of free stack which each
> -	  task has ever had available in the sysrq-T and sysrq-P debug output.
> -
> -	  This option will slow down process creation somewhat.
> -
>  config DEBUG_KOBJECT
>  	bool "kobject debugging"
>  	depends on DEBUG_KERNEL
> @@ -688,13 +804,6 @@ config DEBUG_KOBJECT
>  	  If you say Y here, some extra kobject debugging messages will be sent
>  	  to the syslog. 
> 
> -config DEBUG_HIGHMEM
> -	bool "Highmem debugging"
> -	depends on DEBUG_KERNEL && HIGHMEM
> -	help
> -	  This options enables addition error checking for high memory systems.
> -	  Disable for production systems.
> -
>  config HAVE_DEBUG_BUGVERBOSE
>  	bool
> 
> @@ -733,40 +842,6 @@ config DEBUG_INFO_REDUCED
>  	  DEBUG_INFO build and compile times are reduced too.
>  	  Only works with newer gcc versions.
> 
> -config DEBUG_VM
> -	bool "Debug VM"
> -	depends on DEBUG_KERNEL
> -	help
> -	  Enable this to turn on extended checks in the virtual-memory system
> -          that may impact performance.
> -
> -	  If unsure, say N.
> -
> -config DEBUG_VM_RB
> -	bool "Debug VM red-black trees"
> -	depends on DEBUG_VM
> -	help
> -	  Enable this to turn on more extended checks in the virtual-memory
> -	  system that may impact performance.
> -
> -	  If unsure, say N.
> -
> -config DEBUG_VIRTUAL
> -	bool "Debug VM translations"
> -	depends on DEBUG_KERNEL && X86
> -	help
> -	  Enable some costly sanity checks in virtual to page code. This can
> -	  catch mistakes with virt_to_page() and friends.
> -
> -	  If unsure, say N.
> -
> -config DEBUG_NOMMU_REGIONS
> -	bool "Debug the global anon/private NOMMU mapping region tree"
> -	depends on DEBUG_KERNEL && !MMU
> -	help
> -	  This option causes the global tree of anonymous and private mapping
> -	  regions to be regularly checked for invalid topology.
> -
>  config DEBUG_WRITECOUNT
>  	bool "Debug filesystem writers count"
>  	depends on DEBUG_KERNEL
> @@ -777,18 +852,6 @@ config DEBUG_WRITECOUNT
> 
>  	  If unsure, say N.
> 
> -config DEBUG_MEMORY_INIT
> -	bool "Debug memory initialisation" if EXPERT
> -	default !EXPERT
> -	help
> -	  Enable this for additional checks during memory initialisation.
> -	  The sanity checks verify aspects of the VM such as the memory model
> -	  and other information provided by the architecture. Verbose
> -	  information will be printed at KERN_DEBUG loglevel depending
> -	  on the mminit_loglevel= command-line option.
> -
> -	  If unsure, say Y
> -
>  config DEBUG_LIST
>  	bool "Debug linked list manipulation"
>  	depends on DEBUG_KERNEL
> @@ -1088,17 +1151,6 @@ config DEBUG_FORCE_WEAK_PER_CPU
>  	  To ensure that generic code follows the above rules, this
>  	  option forces all percpu variables to be defined as weak.
> 
> -config DEBUG_PER_CPU_MAPS
> -	bool "Debug access to per_cpu maps"
> -	depends on DEBUG_KERNEL
> -	depends on SMP
> -	help
> -	  Say Y to verify that the per_cpu map being accessed has
> -	  been set up. This adds a fair amount of code to kernel memory
> -	  and decreases performance.
> -
> -	  Say N if unsure.
> -
>  config LKDTM
>  	tristate "Linux Kernel Dump Test Tool Module"
>  	depends on DEBUG_FS
> @@ -1173,29 +1225,6 @@ config PM_NOTIFIER_ERROR_INJECT
> 
>  	  If unsure, say N.
> 
> -config MEMORY_NOTIFIER_ERROR_INJECT
> -	tristate "Memory hotplug notifier error injection module"
> -	depends on MEMORY_HOTPLUG_SPARSE && NOTIFIER_ERROR_INJECTION
> -	help
> -	  This option provides the ability to inject artificial errors to
> -	  memory hotplug notifier chain callbacks.  It is controlled through
> -	  debugfs interface under /sys/kernel/debug/notifier-error-inject/memory
> -
> -	  If the notifier call chain should be failed with some events
> -	  notified, write the error code to "actions/<notifier event>/error".
> -
> -	  Example: Inject memory hotplug offline error (-12 == -ENOMEM)
> -
> -	  # cd /sys/kernel/debug/notifier-error-inject/memory
> -	  # echo -12 > actions/MEM_GOING_OFFLINE/error
> -	  # echo offline > /sys/devices/system/memory/memoryXXX/state
> -	  bash: echo: write error: Cannot allocate memory
> -
> -	  To compile this code as a module, choose M here: the module will
> -	  be called memory-notifier-error-inject.
> -
> -	  If unsure, say N.
> -
>  config OF_RECONFIG_NOTIFIER_ERROR_INJECT
>  	tristate "OF reconfig notifier error injection module"
>  	depends on OF_DYNAMIC && NOTIFIER_ERROR_INJECTION
> @@ -1310,7 +1339,6 @@ config DEBUG_STRICT_USER_COPY_CHECKS
> 
>  	  If unsure, say N.
> 
> -source mm/Kconfig.debug
>  source kernel/trace/Kconfig
> 
>  config RBTREE_TEST
> @@ -1475,33 +1503,10 @@ config ASYNC_RAID6_TEST
> 
>  	  If unsure, say N.
> 
> -config HAVE_DEBUG_STACKOVERFLOW
> -	bool
> -
> -config DEBUG_STACKOVERFLOW
> -	bool "Check for stack overflows"
> -	depends on DEBUG_KERNEL && HAVE_DEBUG_STACKOVERFLOW
> -	---help---
> -	  Say Y here if you want to check for overflows of kernel, IRQ
> -	  and exception stacks (if your archicture uses them). This
> -	  option will show detailed messages if free stack space drops
> -	  below a certain limit.
> -
> -	  These kinds of bugs usually occur when call-chains in the
> -	  kernel get too deep, especially when interrupts are
> -	  involved.
> -
> -	  Use this in cases where you see apparently random memory
> -	  corruption, especially if it appears in 'struct thread_info'
> -
> -	  If in doubt, say "N".
> -
>  source "samples/Kconfig"
> 
>  source "lib/Kconfig.kgdb"
> 
> -source "lib/Kconfig.kmemcheck"
> -
>  config TEST_STRING_HELPERS
>  	tristate "Test functions located in the string_helpers module at runtime"
> 
> _
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/