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