1# 2# Architectures that offer an FUNCTION_TRACER implementation should 3# select HAVE_FUNCTION_TRACER: 4# 5 6config USER_STACKTRACE_SUPPORT 7 bool 8 9config NOP_TRACER 10 bool 11 12config HAVE_FTRACE_NMI_ENTER 13 bool 14 15config HAVE_FUNCTION_TRACER 16 bool 17 18config HAVE_FUNCTION_GRAPH_TRACER 19 bool 20 21config HAVE_FUNCTION_GRAPH_FP_TEST 22 bool 23 help 24 An arch may pass in a unique value (frame pointer) to both the 25 entering and exiting of a function. On exit, the value is compared 26 and if it does not match, then it will panic the kernel. 27 28config HAVE_FUNCTION_TRACE_MCOUNT_TEST 29 bool 30 help 31 This gets selected when the arch tests the function_trace_stop 32 variable at the mcount call site. Otherwise, this variable 33 is tested by the called function. 34 35config HAVE_DYNAMIC_FTRACE 36 bool 37 38config HAVE_FTRACE_MCOUNT_RECORD 39 bool 40 41config HAVE_HW_BRANCH_TRACER 42 bool 43 44config HAVE_SYSCALL_TRACEPOINTS 45 bool 46 47config TRACER_MAX_TRACE 48 bool 49 50config RING_BUFFER 51 bool 52 53config FTRACE_NMI_ENTER 54 bool 55 depends on HAVE_FTRACE_NMI_ENTER 56 default y 57 58config EVENT_TRACING 59 select CONTEXT_SWITCH_TRACER 60 bool 61 62config CONTEXT_SWITCH_TRACER 63 bool 64 65config RING_BUFFER_ALLOW_SWAP 66 bool 67 help 68 Allow the use of ring_buffer_swap_cpu. 69 Adds a very slight overhead to tracing when enabled. 70 71# All tracer options should select GENERIC_TRACER. For those options that are 72# enabled by all tracers (context switch and event tracer) they select TRACING. 73# This allows those options to appear when no other tracer is selected. But the 74# options do not appear when something else selects it. We need the two options 75# GENERIC_TRACER and TRACING to avoid circular dependencies to accomplish the 76# hidding of the automatic options options. 77 78config TRACING 79 bool 80 select DEBUG_FS 81 select RING_BUFFER 82 select STACKTRACE if STACKTRACE_SUPPORT 83 select TRACEPOINTS 84 select NOP_TRACER 85 select BINARY_PRINTF 86 select EVENT_TRACING 87 88config GENERIC_TRACER 89 bool 90 select TRACING 91 92# 93# Minimum requirements an architecture has to meet for us to 94# be able to offer generic tracing facilities: 95# 96config TRACING_SUPPORT 97 bool 98 # PPC32 has no irqflags tracing support, but it can use most of the 99 # tracers anyway, they were tested to build and work. Note that new 100 # exceptions to this list aren't welcomed, better implement the 101 # irqflags tracing for your architecture. 102 depends on TRACE_IRQFLAGS_SUPPORT || PPC32 103 depends on STACKTRACE_SUPPORT 104 default y 105 106if TRACING_SUPPORT 107 108menuconfig FTRACE 109 bool "Tracers" 110 default y if DEBUG_KERNEL 111 help 112 Enable the kernel tracing infrastructure. 113 114if FTRACE 115 116config FUNCTION_TRACER 117 bool "Kernel Function Tracer" 118 depends on HAVE_FUNCTION_TRACER 119 select FRAME_POINTER 120 select KALLSYMS 121 select GENERIC_TRACER 122 select CONTEXT_SWITCH_TRACER 123 help 124 Enable the kernel to trace every kernel function. This is done 125 by using a compiler feature to insert a small, 5-byte No-Operation 126 instruction to the beginning of every kernel function, which NOP 127 sequence is then dynamically patched into a tracer call when 128 tracing is enabled by the administrator. If it's runtime disabled 129 (the bootup default), then the overhead of the instructions is very 130 small and not measurable even in micro-benchmarks. 131 132config FUNCTION_GRAPH_TRACER 133 bool "Kernel Function Graph Tracer" 134 depends on HAVE_FUNCTION_GRAPH_TRACER 135 depends on FUNCTION_TRACER 136 depends on !X86_32 || !CC_OPTIMIZE_FOR_SIZE 137 default y 138 help 139 Enable the kernel to trace a function at both its return 140 and its entry. 141 Its first purpose is to trace the duration of functions and 142 draw a call graph for each thread with some information like 143 the return value. This is done by setting the current return 144 address on the current task structure into a stack of calls. 145 146 147config IRQSOFF_TRACER 148 bool "Interrupts-off Latency Tracer" 149 default n 150 depends on TRACE_IRQFLAGS_SUPPORT 151 depends on GENERIC_TIME 152 select TRACE_IRQFLAGS 153 select GENERIC_TRACER 154 select TRACER_MAX_TRACE 155 select RING_BUFFER_ALLOW_SWAP 156 help 157 This option measures the time spent in irqs-off critical 158 sections, with microsecond accuracy. 159 160 The default measurement method is a maximum search, which is 161 disabled by default and can be runtime (re-)started 162 via: 163 164 echo 0 > /sys/kernel/debug/tracing/tracing_max_latency 165 166 (Note that kernel size and overhead increases with this option 167 enabled. This option and the preempt-off timing option can be 168 used together or separately.) 169 170config PREEMPT_TRACER 171 bool "Preemption-off Latency Tracer" 172 default n 173 depends on GENERIC_TIME 174 depends on PREEMPT 175 select GENERIC_TRACER 176 select TRACER_MAX_TRACE 177 select RING_BUFFER_ALLOW_SWAP 178 help 179 This option measures the time spent in preemption off critical 180 sections, with microsecond accuracy. 181 182 The default measurement method is a maximum search, which is 183 disabled by default and can be runtime (re-)started 184 via: 185 186 echo 0 > /sys/kernel/debug/tracing/tracing_max_latency 187 188 (Note that kernel size and overhead increases with this option 189 enabled. This option and the irqs-off timing option can be 190 used together or separately.) 191 192config SYSPROF_TRACER 193 bool "Sysprof Tracer" 194 depends on X86 195 select GENERIC_TRACER 196 select CONTEXT_SWITCH_TRACER 197 help 198 This tracer provides the trace needed by the 'Sysprof' userspace 199 tool. 200 201config SCHED_TRACER 202 bool "Scheduling Latency Tracer" 203 select GENERIC_TRACER 204 select CONTEXT_SWITCH_TRACER 205 select TRACER_MAX_TRACE 206 help 207 This tracer tracks the latency of the highest priority task 208 to be scheduled in, starting from the point it has woken up. 209 210config ENABLE_DEFAULT_TRACERS 211 bool "Trace process context switches and events" 212 depends on !GENERIC_TRACER 213 select TRACING 214 help 215 This tracer hooks to various trace points in the kernel 216 allowing the user to pick and choose which trace point they 217 want to trace. It also includes the sched_switch tracer plugin. 218 219config FTRACE_SYSCALLS 220 bool "Trace syscalls" 221 depends on HAVE_SYSCALL_TRACEPOINTS 222 select GENERIC_TRACER 223 select KALLSYMS 224 help 225 Basic tracer to catch the syscall entry and exit events. 226 227config BOOT_TRACER 228 bool "Trace boot initcalls" 229 select GENERIC_TRACER 230 select CONTEXT_SWITCH_TRACER 231 help 232 This tracer helps developers to optimize boot times: it records 233 the timings of the initcalls and traces key events and the identity 234 of tasks that can cause boot delays, such as context-switches. 235 236 Its aim is to be parsed by the scripts/bootgraph.pl tool to 237 produce pretty graphics about boot inefficiencies, giving a visual 238 representation of the delays during initcalls - but the raw 239 /debug/tracing/trace text output is readable too. 240 241 You must pass in initcall_debug and ftrace=initcall to the kernel 242 command line to enable this on bootup. 243 244config TRACE_BRANCH_PROFILING 245 bool 246 select GENERIC_TRACER 247 248choice 249 prompt "Branch Profiling" 250 default BRANCH_PROFILE_NONE 251 help 252 The branch profiling is a software profiler. It will add hooks 253 into the C conditionals to test which path a branch takes. 254 255 The likely/unlikely profiler only looks at the conditions that 256 are annotated with a likely or unlikely macro. 257 258 The "all branch" profiler will profile every if statement in the 259 kernel. This profiler will also enable the likely/unlikely 260 profiler as well. 261 262 Either of the above profilers add a bit of overhead to the system. 263 If unsure choose "No branch profiling". 264 265config BRANCH_PROFILE_NONE 266 bool "No branch profiling" 267 help 268 No branch profiling. Branch profiling adds a bit of overhead. 269 Only enable it if you want to analyse the branching behavior. 270 Otherwise keep it disabled. 271 272config PROFILE_ANNOTATED_BRANCHES 273 bool "Trace likely/unlikely profiler" 274 select TRACE_BRANCH_PROFILING 275 help 276 This tracer profiles all the the likely and unlikely macros 277 in the kernel. It will display the results in: 278 279 /sys/kernel/debug/tracing/profile_annotated_branch 280 281 Note: this will add a significant overhead, only turn this 282 on if you need to profile the system's use of these macros. 283 284config PROFILE_ALL_BRANCHES 285 bool "Profile all if conditionals" 286 select TRACE_BRANCH_PROFILING 287 help 288 This tracer profiles all branch conditions. Every if () 289 taken in the kernel is recorded whether it hit or miss. 290 The results will be displayed in: 291 292 /sys/kernel/debug/tracing/profile_branch 293 294 This option also enables the likely/unlikely profiler. 295 296 This configuration, when enabled, will impose a great overhead 297 on the system. This should only be enabled when the system 298 is to be analyzed 299endchoice 300 301config TRACING_BRANCHES 302 bool 303 help 304 Selected by tracers that will trace the likely and unlikely 305 conditions. This prevents the tracers themselves from being 306 profiled. Profiling the tracing infrastructure can only happen 307 when the likelys and unlikelys are not being traced. 308 309config BRANCH_TRACER 310 bool "Trace likely/unlikely instances" 311 depends on TRACE_BRANCH_PROFILING 312 select TRACING_BRANCHES 313 help 314 This traces the events of likely and unlikely condition 315 calls in the kernel. The difference between this and the 316 "Trace likely/unlikely profiler" is that this is not a 317 histogram of the callers, but actually places the calling 318 events into a running trace buffer to see when and where the 319 events happened, as well as their results. 320 321 Say N if unsure. 322 323config POWER_TRACER 324 bool "Trace power consumption behavior" 325 depends on X86 326 select GENERIC_TRACER 327 help 328 This tracer helps developers to analyze and optimize the kernels 329 power management decisions, specifically the C-state and P-state 330 behavior. 331 332 333config STACK_TRACER 334 bool "Trace max stack" 335 depends on HAVE_FUNCTION_TRACER 336 select FUNCTION_TRACER 337 select STACKTRACE 338 select KALLSYMS 339 help 340 This special tracer records the maximum stack footprint of the 341 kernel and displays it in /sys/kernel/debug/tracing/stack_trace. 342 343 This tracer works by hooking into every function call that the 344 kernel executes, and keeping a maximum stack depth value and 345 stack-trace saved. If this is configured with DYNAMIC_FTRACE 346 then it will not have any overhead while the stack tracer 347 is disabled. 348 349 To enable the stack tracer on bootup, pass in 'stacktrace' 350 on the kernel command line. 351 352 The stack tracer can also be enabled or disabled via the 353 sysctl kernel.stack_tracer_enabled 354 355 Say N if unsure. 356 357config HW_BRANCH_TRACER 358 depends on HAVE_HW_BRANCH_TRACER 359 bool "Trace hw branches" 360 select GENERIC_TRACER 361 help 362 This tracer records all branches on the system in a circular 363 buffer giving access to the last N branches for each cpu. 364 365config KMEMTRACE 366 bool "Trace SLAB allocations" 367 select GENERIC_TRACER 368 help 369 kmemtrace provides tracing for slab allocator functions, such as 370 kmalloc, kfree, kmem_cache_alloc, kmem_cache_free etc.. Collected 371 data is then fed to the userspace application in order to analyse 372 allocation hotspots, internal fragmentation and so on, making it 373 possible to see how well an allocator performs, as well as debug 374 and profile kernel code. 375 376 This requires an userspace application to use. See 377 Documentation/trace/kmemtrace.txt for more information. 378 379 Saying Y will make the kernel somewhat larger and slower. However, 380 if you disable kmemtrace at run-time or boot-time, the performance 381 impact is minimal (depending on the arch the kernel is built for). 382 383 If unsure, say N. 384 385config WORKQUEUE_TRACER 386 bool "Trace workqueues" 387 select GENERIC_TRACER 388 help 389 The workqueue tracer provides some statistical informations 390 about each cpu workqueue thread such as the number of the 391 works inserted and executed since their creation. It can help 392 to evaluate the amount of work each of them have to perform. 393 For example it can help a developer to decide whether he should 394 choose a per cpu workqueue instead of a singlethreaded one. 395 396config BLK_DEV_IO_TRACE 397 bool "Support for tracing block io actions" 398 depends on SYSFS 399 depends on BLOCK 400 select RELAY 401 select DEBUG_FS 402 select TRACEPOINTS 403 select GENERIC_TRACER 404 select STACKTRACE 405 help 406 Say Y here if you want to be able to trace the block layer actions 407 on a given queue. Tracing allows you to see any traffic happening 408 on a block device queue. For more information (and the userspace 409 support tools needed), fetch the blktrace tools from: 410 411 git://git.kernel.dk/blktrace.git 412 413 Tracing also is possible using the ftrace interface, e.g.: 414 415 echo 1 > /sys/block/sda/sda1/trace/enable 416 echo blk > /sys/kernel/debug/tracing/current_tracer 417 cat /sys/kernel/debug/tracing/trace_pipe 418 419 If unsure, say N. 420 421config DYNAMIC_FTRACE 422 bool "enable/disable ftrace tracepoints dynamically" 423 depends on FUNCTION_TRACER 424 depends on HAVE_DYNAMIC_FTRACE 425 default y 426 help 427 This option will modify all the calls to ftrace dynamically 428 (will patch them out of the binary image and replaces them 429 with a No-Op instruction) as they are called. A table is 430 created to dynamically enable them again. 431 432 This way a CONFIG_FUNCTION_TRACER kernel is slightly larger, but otherwise 433 has native performance as long as no tracing is active. 434 435 The changes to the code are done by a kernel thread that 436 wakes up once a second and checks to see if any ftrace calls 437 were made. If so, it runs stop_machine (stops all CPUS) 438 and modifies the code to jump over the call to ftrace. 439 440config FUNCTION_PROFILER 441 bool "Kernel function profiler" 442 depends on FUNCTION_TRACER 443 default n 444 help 445 This option enables the kernel function profiler. A file is created 446 in debugfs called function_profile_enabled which defaults to zero. 447 When a 1 is echoed into this file profiling begins, and when a 448 zero is entered, profiling stops. A file in the trace_stats 449 directory called functions, that show the list of functions that 450 have been hit and their counters. 451 452 If in doubt, say N 453 454config FTRACE_MCOUNT_RECORD 455 def_bool y 456 depends on DYNAMIC_FTRACE 457 depends on HAVE_FTRACE_MCOUNT_RECORD 458 459config FTRACE_SELFTEST 460 bool 461 462config FTRACE_STARTUP_TEST 463 bool "Perform a startup test on ftrace" 464 depends on GENERIC_TRACER 465 select FTRACE_SELFTEST 466 help 467 This option performs a series of startup tests on ftrace. On bootup 468 a series of tests are made to verify that the tracer is 469 functioning properly. It will do tests on all the configured 470 tracers of ftrace. 471 472config MMIOTRACE 473 bool "Memory mapped IO tracing" 474 depends on HAVE_MMIOTRACE_SUPPORT && PCI 475 select GENERIC_TRACER 476 help 477 Mmiotrace traces Memory Mapped I/O access and is meant for 478 debugging and reverse engineering. It is called from the ioremap 479 implementation and works via page faults. Tracing is disabled by 480 default and can be enabled at run-time. 481 482 See Documentation/trace/mmiotrace.txt. 483 If you are not helping to develop drivers, say N. 484 485config MMIOTRACE_TEST 486 tristate "Test module for mmiotrace" 487 depends on MMIOTRACE && m 488 help 489 This is a dumb module for testing mmiotrace. It is very dangerous 490 as it will write garbage to IO memory starting at a given address. 491 However, it should be safe to use on e.g. unused portion of VRAM. 492 493 Say N, unless you absolutely know what you are doing. 494 495config RING_BUFFER_BENCHMARK 496 tristate "Ring buffer benchmark stress tester" 497 depends on RING_BUFFER 498 help 499 This option creates a test to stress the ring buffer and bench mark it. 500 It creates its own ring buffer such that it will not interfer with 501 any other users of the ring buffer (such as ftrace). It then creates 502 a producer and consumer that will run for 10 seconds and sleep for 503 10 seconds. Each interval it will print out the number of events 504 it recorded and give a rough estimate of how long each iteration took. 505 506 It does not disable interrupts or raise its priority, so it may be 507 affected by processes that are running. 508 509 If unsure, say N 510 511endif # FTRACE 512 513endif # TRACING_SUPPORT 514 515