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