SAFE public projects git trees. - safe/jmp/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         help
 138           This tracer provides the trace needed by the 'Sysprof' userspace
 139           tool.
 140
 141 config SCHED_TRACER
 142         bool "Scheduling Latency Tracer"
 143         depends on DEBUG_KERNEL
 144         select TRACING
 145         select CONTEXT_SWITCH_TRACER
 146         select TRACER_MAX_TRACE
 147         help
 148           This tracer tracks the latency of the highest priority task
 149           to be scheduled in, starting from the point it has woken up.
 150
 151 config CONTEXT_SWITCH_TRACER
 152         bool "Trace process context switches"
 153         depends on DEBUG_KERNEL
 154         select TRACING
 155         select MARKERS
 156         help
 157           This tracer gets called from the context switch and records
 158           all switching of tasks.
 159
 160 config BOOT_TRACER
 161         bool "Trace boot initcalls"
 162         depends on DEBUG_KERNEL
 163         select TRACING
 164         select CONTEXT_SWITCH_TRACER
 165         help
 166           This tracer helps developers to optimize boot times: it records
 167           the timings of the initcalls and traces key events and the identity
 168           of tasks that can cause boot delays, such as context-switches.
 169
 170           Its aim is to be parsed by the /scripts/bootgraph.pl tool to
 171           produce pretty graphics about boot inefficiencies, giving a visual
 172           representation of the delays during initcalls - but the raw
 173           /debug/tracing/trace text output is readable too.
 174
 175           You must pass in ftrace=initcall to the kernel command line
 176           to enable this on bootup.
 177
 178 config TRACE_BRANCH_PROFILING
 179         bool "Trace likely/unlikely profiler"
 180         depends on DEBUG_KERNEL
 181         select TRACING
 182         help
 183           This tracer profiles all the the likely and unlikely macros
 184           in the kernel. It will display the results in:
 185
 186           /debugfs/tracing/profile_annotated_branch
 187
 188           Note: this will add a significant overhead, only turn this
 189           on if you need to profile the system's use of these macros.
 190
 191           Say N if unsure.
 192
 193 config PROFILE_ALL_BRANCHES
 194         bool "Profile all if conditionals"
 195         depends on TRACE_BRANCH_PROFILING
 196         help
 197           This tracer profiles all branch conditions. Every if ()
 198           taken in the kernel is recorded whether it hit or miss.
 199           The results will be displayed in:
 200
 201           /debugfs/tracing/profile_branch
 202
 203           This configuration, when enabled, will impose a great overhead
 204           on the system. This should only be enabled when the system
 205           is to be analyzed
 206
 207           Say N if unsure.
 208
 209 config TRACING_BRANCHES
 210         bool
 211         help
 212           Selected by tracers that will trace the likely and unlikely
 213           conditions. This prevents the tracers themselves from being
 214           profiled. Profiling the tracing infrastructure can only happen
 215           when the likelys and unlikelys are not being traced.
 216
 217 config BRANCH_TRACER
 218         bool "Trace likely/unlikely instances"
 219         depends on TRACE_BRANCH_PROFILING
 220         select TRACING_BRANCHES
 221         help
 222           This traces the events of likely and unlikely condition
 223           calls in the kernel.  The difference between this and the
 224           "Trace likely/unlikely profiler" is that this is not a
 225           histogram of the callers, but actually places the calling
 226           events into a running trace buffer to see when and where the
 227           events happened, as well as their results.
 228
 229           Say N if unsure.
 230
 231 config POWER_TRACER
 232         bool "Trace power consumption behavior"
 233         depends on DEBUG_KERNEL
 234         depends on X86
 235         select TRACING
 236         help
 237           This tracer helps developers to analyze and optimize the kernels
 238           power management decisions, specifically the C-state and P-state
 239           behavior.
 240
 241
 242 config STACK_TRACER
 243         bool "Trace max stack"
 244         depends on HAVE_FUNCTION_TRACER
 245         depends on DEBUG_KERNEL
 246         select FUNCTION_TRACER
 247         select STACKTRACE
 248         help
 249           This special tracer records the maximum stack footprint of the
 250           kernel and displays it in debugfs/tracing/stack_trace.
 251
 252           This tracer works by hooking into every function call that the
 253           kernel executes, and keeping a maximum stack depth value and
 254           stack-trace saved.  If this is configured with DYNAMIC_FTRACE
 255           then it will not have any overhead while the stack tracer
 256           is disabled.
 257
 258           To enable the stack tracer on bootup, pass in 'stacktrace'
 259           on the kernel command line.
 260
 261           The stack tracer can also be enabled or disabled via the
 262           sysctl kernel.stack_tracer_enabled
 263
 264           Say N if unsure.
 265
 266 config HW_BRANCH_TRACER
 267         depends on HAVE_HW_BRANCH_TRACER
 268         bool "Trace hw branches"
 269         select TRACING
 270         help
 271           This tracer records all branches on the system in a circular
 272           buffer giving access to the last N branches for each cpu.
 273
 274 config KMEMTRACE
 275         bool "Trace SLAB allocations"
 276         select TRACING
 277         help
 278           kmemtrace provides tracing for slab allocator functions, such as
 279           kmalloc, kfree, kmem_cache_alloc, kmem_cache_free etc.. Collected
 280           data is then fed to the userspace application in order to analyse
 281           allocation hotspots, internal fragmentation and so on, making it
 282           possible to see how well an allocator performs, as well as debug
 283           and profile kernel code.
 284
 285           This requires an userspace application to use. See
 286           Documentation/vm/kmemtrace.txt for more information.
 287
 288           Saying Y will make the kernel somewhat larger and slower. However,
 289           if you disable kmemtrace at run-time or boot-time, the performance
 290           impact is minimal (depending on the arch the kernel is built for).
 291
 292           If unsure, say N.
 293
 294 config WORKQUEUE_TRACER
 295         bool "Trace workqueues"
 296         select TRACING
 297         help
 298           The workqueue tracer provides some statistical informations
 299           about each cpu workqueue thread such as the number of the
 300           works inserted and executed since their creation. It can help
 301           to evaluate the amount of work each of them have to perform.
 302           For example it can help a developer to decide whether he should
 303           choose a per cpu workqueue instead of a singlethreaded one.
 304
 305 config BLK_DEV_IO_TRACE
 306         bool "Support for tracing block io actions"
 307         depends on SYSFS
 308         depends on BLOCK
 309         select RELAY
 310         select DEBUG_FS
 311         select TRACEPOINTS
 312         select TRACING
 313         select STACKTRACE
 314         help
 315           Say Y here if you want to be able to trace the block layer actions
 316           on a given queue. Tracing allows you to see any traffic happening
 317           on a block device queue. For more information (and the userspace
 318           support tools needed), fetch the blktrace tools from:
 319
 320           git://git.kernel.dk/blktrace.git
 321
 322           Tracing also is possible using the ftrace interface, e.g.:
 323
 324             echo 1 > /sys/block/sda/sda1/trace/enable
 325             echo blk > /sys/kernel/debug/tracing/current_tracer
 326             cat /sys/kernel/debug/tracing/trace_pipe
 327
 328           If unsure, say N.
 329
 330 config DYNAMIC_FTRACE
 331         bool "enable/disable ftrace tracepoints dynamically"
 332         depends on FUNCTION_TRACER
 333         depends on HAVE_DYNAMIC_FTRACE
 334         depends on DEBUG_KERNEL
 335         default y
 336         help
 337          This option will modify all the calls to ftrace dynamically
 338          (will patch them out of the binary image and replaces them
 339          with a No-Op instruction) as they are called. A table is
 340          created to dynamically enable them again.
 341
 342          This way a CONFIG_FUNCTION_TRACER kernel is slightly larger, but otherwise
 343          has native performance as long as no tracing is active.
 344
 345          The changes to the code are done by a kernel thread that
 346          wakes up once a second and checks to see if any ftrace calls
 347          were made. If so, it runs stop_machine (stops all CPUS)
 348          and modifies the code to jump over the call to ftrace.
 349
 350 config FTRACE_MCOUNT_RECORD
 351         def_bool y
 352         depends on DYNAMIC_FTRACE
 353         depends on HAVE_FTRACE_MCOUNT_RECORD
 354
 355 config FTRACE_SELFTEST
 356         bool
 357
 358 config FTRACE_STARTUP_TEST
 359         bool "Perform a startup test on ftrace"
 360         depends on TRACING && DEBUG_KERNEL
 361         select FTRACE_SELFTEST
 362         help
 363           This option performs a series of startup tests on ftrace. On bootup
 364           a series of tests are made to verify that the tracer is
 365           functioning properly. It will do tests on all the configured
 366           tracers of ftrace.
 367
 368 config MMIOTRACE
 369         bool "Memory mapped IO tracing"
 370         depends on HAVE_MMIOTRACE_SUPPORT && DEBUG_KERNEL && PCI
 371         select TRACING
 372         help
 373           Mmiotrace traces Memory Mapped I/O access and is meant for
 374           debugging and reverse engineering. It is called from the ioremap
 375           implementation and works via page faults. Tracing is disabled by
 376           default and can be enabled at run-time.
 377
 378           See Documentation/tracers/mmiotrace.txt.
 379           If you are not helping to develop drivers, say N.
 380
 381 config MMIOTRACE_TEST
 382         tristate "Test module for mmiotrace"
 383         depends on MMIOTRACE && m
 384         help
 385           This is a dumb module for testing mmiotrace. It is very dangerous
 386           as it will write garbage to IO memory starting at a given address.
 387           However, it should be safe to use on e.g. unused portion of VRAM.
 388
 389           Say N, unless you absolutely know what you are doing.
 390
 391 endmenu