git.oblomov.eu Git - linux-2.6/blob - kernel/trace/Kconfig

   1 #
   2 # Architectures that offer an FUNCTION_TRACER implementation should
   3 #  select HAVE_FUNCTION_TRACER:
   4 #
   5
   6 config USER_STACKTRACE_SUPPORT
   7         bool
   8
   9 config NOP_TRACER
  10         bool
  11
  12 config HAVE_FTRACE_NMI_ENTER
  13         bool
  14
  15 config HAVE_FUNCTION_TRACER
  16         bool
  17
  18 config HAVE_FUNCTION_GRAPH_TRACER
  19         bool
  20
  21 config HAVE_FUNCTION_TRACE_MCOUNT_TEST
  22         bool
  23         help
  24          This gets selected when the arch tests the function_trace_stop
  25          variable at the mcount call site. Otherwise, this variable
  26          is tested by the called function.
  27
  28 config HAVE_DYNAMIC_FTRACE
  29         bool
  30
  31 config HAVE_FTRACE_MCOUNT_RECORD
  32         bool
  33
  34 config HAVE_HW_BRANCH_TRACER
  35         bool
  36
  37 config TRACER_MAX_TRACE
  38         bool
  39
  40 config RING_BUFFER
  41         bool
  42
  43 config FTRACE_NMI_ENTER
  44        bool
  45        depends on HAVE_FTRACE_NMI_ENTER
  46        default y
  47
  48 config TRACING
  49         bool
  50         select DEBUG_FS
  51         select RING_BUFFER
  52         select STACKTRACE if STACKTRACE_SUPPORT
  53         select TRACEPOINTS
  54         select NOP_TRACER
  55
  56 menu "Tracers"
  57
  58 config FUNCTION_TRACER
  59         bool "Kernel Function Tracer"
  60         depends on HAVE_FUNCTION_TRACER
  61         depends on DEBUG_KERNEL
  62         select FRAME_POINTER
  63         select TRACING
  64         select CONTEXT_SWITCH_TRACER
  65         help
  66           Enable the kernel to trace every kernel function. This is done
  67           by using a compiler feature to insert a small, 5-byte No-Operation
  68           instruction to the beginning of every kernel function, which NOP
  69           sequence is then dynamically patched into a tracer call when
  70           tracing is enabled by the administrator. If it's runtime disabled
  71           (the bootup default), then the overhead of the instructions is very
  72           small and not measurable even in micro-benchmarks.
  73
  74 config FUNCTION_GRAPH_TRACER
  75         bool "Kernel Function Graph Tracer"
  76         depends on HAVE_FUNCTION_GRAPH_TRACER
  77         depends on FUNCTION_TRACER
  78         default y
  79         help
  80           Enable the kernel to trace a function at both its return
  81           and its entry.
  82           It's first purpose is to trace the duration of functions and
  83           draw a call graph for each thread with some informations like
  84           the return value.
  85           This is done by setting the current return address on the current
  86           task structure into a stack of calls.
  87
  88 config IRQSOFF_TRACER
  89         bool "Interrupts-off Latency Tracer"
  90         default n
  91         depends on TRACE_IRQFLAGS_SUPPORT
  92         depends on GENERIC_TIME
  93         depends on DEBUG_KERNEL
  94         select TRACE_IRQFLAGS
  95         select TRACING
  96         select TRACER_MAX_TRACE
  97         help
  98           This option measures the time spent in irqs-off critical
  99           sections, with microsecond accuracy.
 100
 101           The default measurement method is a maximum search, which is
 102           disabled by default and can be runtime (re-)started
 103           via:
 104
 105               echo 0 > /debugfs/tracing/tracing_max_latency
 106
 107           (Note that kernel size and overhead increases with this option
 108           enabled. This option and the preempt-off timing option can be
 109           used together or separately.)
 110
 111 config PREEMPT_TRACER
 112         bool "Preemption-off Latency Tracer"
 113         default n
 114         depends on GENERIC_TIME
 115         depends on PREEMPT
 116         depends on DEBUG_KERNEL
 117         select TRACING
 118         select TRACER_MAX_TRACE
 119         help
 120           This option measures the time spent in preemption off critical
 121           sections, with microsecond accuracy.
 122
 123           The default measurement method is a maximum search, which is
 124           disabled by default and can be runtime (re-)started
 125           via:
 126
 127               echo 0 > /debugfs/tracing/tracing_max_latency
 128
 129           (Note that kernel size and overhead increases with this option
 130           enabled. This option and the irqs-off timing option can be
 131           used together or separately.)
 132
 133 config SYSPROF_TRACER
 134         bool "Sysprof Tracer"
 135         depends on X86
 136         select TRACING
 137         select CONTEXT_SWITCH_TRACER
 138         help
 139           This tracer provides the trace needed by the 'Sysprof' userspace
 140           tool.
 141
 142 config SCHED_TRACER
 143         bool "Scheduling Latency Tracer"
 144         depends on DEBUG_KERNEL
 145         select TRACING
 146         select CONTEXT_SWITCH_TRACER
 147         select TRACER_MAX_TRACE
 148         help
 149           This tracer tracks the latency of the highest priority task
 150           to be scheduled in, starting from the point it has woken up.
 151
 152 config CONTEXT_SWITCH_TRACER
 153         bool "Trace process context switches"
 154         depends on DEBUG_KERNEL
 155         select TRACING
 156         select MARKERS
 157         help
 158           This tracer gets called from the context switch and records
 159           all switching of tasks.
 160
 161 config BOOT_TRACER
 162         bool "Trace boot initcalls"
 163         depends on DEBUG_KERNEL
 164         select TRACING
 165         select CONTEXT_SWITCH_TRACER
 166         help
 167           This tracer helps developers to optimize boot times: it records
 168           the timings of the initcalls and traces key events and the identity
 169           of tasks that can cause boot delays, such as context-switches.
 170
 171           Its aim is to be parsed by the /scripts/bootgraph.pl tool to
 172           produce pretty graphics about boot inefficiencies, giving a visual
 173           representation of the delays during initcalls - but the raw
 174           /debug/tracing/trace text output is readable too.
 175
 176           You must pass in ftrace=initcall to the kernel command line
 177           to enable this on bootup.
 178
 179 config TRACE_BRANCH_PROFILING
 180         bool "Trace likely/unlikely profiler"
 181         depends on DEBUG_KERNEL
 182         select TRACING
 183         help
 184           This tracer profiles all the the likely and unlikely macros
 185           in the kernel. It will display the results in:
 186
 187           /debugfs/tracing/profile_annotated_branch
 188
 189           Note: this will add a significant overhead, only turn this
 190           on if you need to profile the system's use of these macros.
 191
 192           Say N if unsure.
 193
 194 config PROFILE_ALL_BRANCHES
 195         bool "Profile all if conditionals"
 196         depends on TRACE_BRANCH_PROFILING
 197         help
 198           This tracer profiles all branch conditions. Every if ()
 199           taken in the kernel is recorded whether it hit or miss.
 200           The results will be displayed in:
 201
 202           /debugfs/tracing/profile_branch
 203
 204           This configuration, when enabled, will impose a great overhead
 205           on the system. This should only be enabled when the system
 206           is to be analyzed
 207
 208           Say N if unsure.
 209
 210 config TRACING_BRANCHES
 211         bool
 212         help
 213           Selected by tracers that will trace the likely and unlikely
 214           conditions. This prevents the tracers themselves from being
 215           profiled. Profiling the tracing infrastructure can only happen
 216           when the likelys and unlikelys are not being traced.
 217
 218 config BRANCH_TRACER
 219         bool "Trace likely/unlikely instances"
 220         depends on TRACE_BRANCH_PROFILING
 221         select TRACING_BRANCHES
 222         help
 223           This traces the events of likely and unlikely condition
 224           calls in the kernel.  The difference between this and the
 225           "Trace likely/unlikely profiler" is that this is not a
 226           histogram of the callers, but actually places the calling
 227           events into a running trace buffer to see when and where the
 228           events happened, as well as their results.
 229
 230           Say N if unsure.
 231
 232 config POWER_TRACER
 233         bool "Trace power consumption behavior"
 234         depends on DEBUG_KERNEL
 235         depends on X86
 236         select TRACING
 237         help
 238           This tracer helps developers to analyze and optimize the kernels
 239           power management decisions, specifically the C-state and P-state
 240           behavior.
 241
 242
 243 config STACK_TRACER
 244         bool "Trace max stack"
 245         depends on HAVE_FUNCTION_TRACER
 246         depends on DEBUG_KERNEL
 247         select FUNCTION_TRACER
 248         select STACKTRACE
 249         help
 250           This special tracer records the maximum stack footprint of the
 251           kernel and displays it in debugfs/tracing/stack_trace.
 252
 253           This tracer works by hooking into every function call that the
 254           kernel executes, and keeping a maximum stack depth value and
 255           stack-trace saved.  If this is configured with DYNAMIC_FTRACE
 256           then it will not have any overhead while the stack tracer
 257           is disabled.
 258
 259           To enable the stack tracer on bootup, pass in 'stacktrace'
 260           on the kernel command line.
 261
 262           The stack tracer can also be enabled or disabled via the
 263           sysctl kernel.stack_tracer_enabled
 264
 265           Say N if unsure.
 266
 267 config HW_BRANCH_TRACER
 268         depends on HAVE_HW_BRANCH_TRACER
 269         bool "Trace hw branches"
 270         select TRACING
 271         help
 272           This tracer records all branches on the system in a circular
 273           buffer giving access to the last N branches for each cpu.
 274
 275 config KMEMTRACE
 276         bool "Trace SLAB allocations"
 277         select TRACING
 278         help
 279           kmemtrace provides tracing for slab allocator functions, such as
 280           kmalloc, kfree, kmem_cache_alloc, kmem_cache_free etc.. Collected
 281           data is then fed to the userspace application in order to analyse
 282           allocation hotspots, internal fragmentation and so on, making it
 283           possible to see how well an allocator performs, as well as debug
 284           and profile kernel code.
 285
 286           This requires an userspace application to use. See
 287           Documentation/vm/kmemtrace.txt for more information.
 288
 289           Saying Y will make the kernel somewhat larger and slower. However,
 290           if you disable kmemtrace at run-time or boot-time, the performance
 291           impact is minimal (depending on the arch the kernel is built for).
 292
 293           If unsure, say N.
 294
 295 config WORKQUEUE_TRACER
 296         bool "Trace workqueues"
 297         select TRACING
 298         help
 299           The workqueue tracer provides some statistical informations
 300           about each cpu workqueue thread such as the number of the
 301           works inserted and executed since their creation. It can help
 302           to evaluate the amount of work each of them have to perform.
 303           For example it can help a developer to decide whether he should
 304           choose a per cpu workqueue instead of a singlethreaded one.
 305
 306 config BLK_DEV_IO_TRACE
 307         bool "Support for tracing block io actions"
 308         depends on SYSFS
 309         depends on BLOCK
 310         select RELAY
 311         select DEBUG_FS
 312         select TRACEPOINTS
 313         select TRACING
 314         select STACKTRACE
 315         help
 316           Say Y here if you want to be able to trace the block layer actions
 317           on a given queue. Tracing allows you to see any traffic happening
 318           on a block device queue. For more information (and the userspace
 319           support tools needed), fetch the blktrace tools from:
 320
 321           git://git.kernel.dk/blktrace.git
 322
 323           Tracing also is possible using the ftrace interface, e.g.:
 324
 325             echo 1 > /sys/block/sda/sda1/trace/enable
 326             echo blk > /sys/kernel/debug/tracing/current_tracer
 327             cat /sys/kernel/debug/tracing/trace_pipe
 328
 329           If unsure, say N.
 330
 331 config DYNAMIC_FTRACE
 332         bool "enable/disable ftrace tracepoints dynamically"
 333         depends on FUNCTION_TRACER
 334         depends on HAVE_DYNAMIC_FTRACE
 335         depends on DEBUG_KERNEL
 336         default y
 337         help
 338          This option will modify all the calls to ftrace dynamically
 339          (will patch them out of the binary image and replaces them
 340          with a No-Op instruction) as they are called. A table is
 341          created to dynamically enable them again.
 342
 343          This way a CONFIG_FUNCTION_TRACER kernel is slightly larger, but otherwise
 344          has native performance as long as no tracing is active.
 345
 346          The changes to the code are done by a kernel thread that
 347          wakes up once a second and checks to see if any ftrace calls
 348          were made. If so, it runs stop_machine (stops all CPUS)
 349          and modifies the code to jump over the call to ftrace.
 350
 351 config FTRACE_MCOUNT_RECORD
 352         def_bool y
 353         depends on DYNAMIC_FTRACE
 354         depends on HAVE_FTRACE_MCOUNT_RECORD
 355
 356 config FTRACE_SELFTEST
 357         bool
 358
 359 config FTRACE_STARTUP_TEST
 360         bool "Perform a startup test on ftrace"
 361         depends on TRACING && DEBUG_KERNEL
 362         select FTRACE_SELFTEST
 363         help
 364           This option performs a series of startup tests on ftrace. On bootup
 365           a series of tests are made to verify that the tracer is
 366           functioning properly. It will do tests on all the configured
 367           tracers of ftrace.
 368
 369 config MMIOTRACE
 370         bool "Memory mapped IO tracing"
 371         depends on HAVE_MMIOTRACE_SUPPORT && DEBUG_KERNEL && PCI
 372         select TRACING
 373         help
 374           Mmiotrace traces Memory Mapped I/O access and is meant for
 375           debugging and reverse engineering. It is called from the ioremap
 376           implementation and works via page faults. Tracing is disabled by
 377           default and can be enabled at run-time.
 378
 379           See Documentation/tracers/mmiotrace.txt.
 380           If you are not helping to develop drivers, say N.
 381
 382 config MMIOTRACE_TEST
 383         tristate "Test module for mmiotrace"
 384         depends on MMIOTRACE && m
 385         help
 386           This is a dumb module for testing mmiotrace. It is very dangerous
 387           as it will write garbage to IO memory starting at a given address.
 388           However, it should be safe to use on e.g. unused portion of VRAM.
 389
 390           Say N, unless you absolutely know what you are doing.
 391
 392 endmenu