| 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 | help |
| 15 | See Documentation/trace/ftrace-design.txt |
| 16 | |
| 17 | config HAVE_FUNCTION_TRACER |
| 18 | bool |
| 19 | help |
| 20 | See Documentation/trace/ftrace-design.txt |
| 21 | |
| 22 | config HAVE_FUNCTION_GRAPH_TRACER |
| 23 | bool |
| 24 | help |
| 25 | See Documentation/trace/ftrace-design.txt |
| 26 | |
| 27 | config HAVE_DYNAMIC_FTRACE |
| 28 | bool |
| 29 | help |
| 30 | See Documentation/trace/ftrace-design.txt |
| 31 | |
| 32 | config HAVE_DYNAMIC_FTRACE_WITH_REGS |
| 33 | bool |
| 34 | |
| 35 | config HAVE_FTRACE_MCOUNT_RECORD |
| 36 | bool |
| 37 | help |
| 38 | See Documentation/trace/ftrace-design.txt |
| 39 | |
| 40 | config HAVE_SYSCALL_TRACEPOINTS |
| 41 | bool |
| 42 | help |
| 43 | See Documentation/trace/ftrace-design.txt |
| 44 | |
| 45 | config HAVE_FENTRY |
| 46 | bool |
| 47 | help |
| 48 | Arch supports the gcc options -pg with -mfentry |
| 49 | |
| 50 | config HAVE_C_RECORDMCOUNT |
| 51 | bool |
| 52 | help |
| 53 | C version of recordmcount available? |
| 54 | |
| 55 | config TRACER_MAX_TRACE |
| 56 | bool |
| 57 | |
| 58 | config TRACE_CLOCK |
| 59 | bool |
| 60 | |
| 61 | config RING_BUFFER |
| 62 | bool |
| 63 | select TRACE_CLOCK |
| 64 | select IRQ_WORK |
| 65 | |
| 66 | config FTRACE_NMI_ENTER |
| 67 | bool |
| 68 | depends on HAVE_FTRACE_NMI_ENTER |
| 69 | default y |
| 70 | |
| 71 | config EVENT_TRACING |
| 72 | select CONTEXT_SWITCH_TRACER |
| 73 | select GLOB |
| 74 | bool |
| 75 | |
| 76 | config CONTEXT_SWITCH_TRACER |
| 77 | bool |
| 78 | |
| 79 | config RING_BUFFER_ALLOW_SWAP |
| 80 | bool |
| 81 | help |
| 82 | Allow the use of ring_buffer_swap_cpu. |
| 83 | Adds a very slight overhead to tracing when enabled. |
| 84 | |
| 85 | # All tracer options should select GENERIC_TRACER. For those options that are |
| 86 | # enabled by all tracers (context switch and event tracer) they select TRACING. |
| 87 | # This allows those options to appear when no other tracer is selected. But the |
| 88 | # options do not appear when something else selects it. We need the two options |
| 89 | # GENERIC_TRACER and TRACING to avoid circular dependencies to accomplish the |
| 90 | # hiding of the automatic options. |
| 91 | |
| 92 | config TRACING |
| 93 | bool |
| 94 | select DEBUG_FS |
| 95 | select RING_BUFFER |
| 96 | select STACKTRACE if STACKTRACE_SUPPORT |
| 97 | select TRACEPOINTS |
| 98 | select NOP_TRACER |
| 99 | select BINARY_PRINTF |
| 100 | select EVENT_TRACING |
| 101 | select TRACE_CLOCK |
| 102 | |
| 103 | config GENERIC_TRACER |
| 104 | bool |
| 105 | select TRACING |
| 106 | |
| 107 | # |
| 108 | # Minimum requirements an architecture has to meet for us to |
| 109 | # be able to offer generic tracing facilities: |
| 110 | # |
| 111 | config TRACING_SUPPORT |
| 112 | bool |
| 113 | # PPC32 has no irqflags tracing support, but it can use most of the |
| 114 | # tracers anyway, they were tested to build and work. Note that new |
| 115 | # exceptions to this list aren't welcomed, better implement the |
| 116 | # irqflags tracing for your architecture. |
| 117 | depends on TRACE_IRQFLAGS_SUPPORT || PPC32 |
| 118 | depends on STACKTRACE_SUPPORT |
| 119 | default y |
| 120 | |
| 121 | if TRACING_SUPPORT |
| 122 | |
| 123 | menuconfig FTRACE |
| 124 | bool "Tracers" |
| 125 | default y if DEBUG_KERNEL |
| 126 | help |
| 127 | Enable the kernel tracing infrastructure. |
| 128 | |
| 129 | if FTRACE |
| 130 | |
| 131 | config FUNCTION_TRACER |
| 132 | bool "Kernel Function Tracer" |
| 133 | depends on HAVE_FUNCTION_TRACER |
| 134 | select KALLSYMS |
| 135 | select GENERIC_TRACER |
| 136 | select CONTEXT_SWITCH_TRACER |
| 137 | select GLOB |
| 138 | select TASKS_RCU if PREEMPT |
| 139 | help |
| 140 | Enable the kernel to trace every kernel function. This is done |
| 141 | by using a compiler feature to insert a small, 5-byte No-Operation |
| 142 | instruction at the beginning of every kernel function, which NOP |
| 143 | sequence is then dynamically patched into a tracer call when |
| 144 | tracing is enabled by the administrator. If it's runtime disabled |
| 145 | (the bootup default), then the overhead of the instructions is very |
| 146 | small and not measurable even in micro-benchmarks. |
| 147 | |
| 148 | config FUNCTION_GRAPH_TRACER |
| 149 | bool "Kernel Function Graph Tracer" |
| 150 | depends on HAVE_FUNCTION_GRAPH_TRACER |
| 151 | depends on FUNCTION_TRACER |
| 152 | depends on !X86_32 || !CC_OPTIMIZE_FOR_SIZE |
| 153 | default y |
| 154 | help |
| 155 | Enable the kernel to trace a function at both its return |
| 156 | and its entry. |
| 157 | Its first purpose is to trace the duration of functions and |
| 158 | draw a call graph for each thread with some information like |
| 159 | the return value. This is done by setting the current return |
| 160 | address on the current task structure into a stack of calls. |
| 161 | |
| 162 | |
| 163 | config IRQSOFF_TRACER |
| 164 | bool "Interrupts-off Latency Tracer" |
| 165 | default n |
| 166 | depends on TRACE_IRQFLAGS_SUPPORT |
| 167 | depends on !ARCH_USES_GETTIMEOFFSET |
| 168 | select TRACE_IRQFLAGS |
| 169 | select GENERIC_TRACER |
| 170 | select TRACER_MAX_TRACE |
| 171 | select RING_BUFFER_ALLOW_SWAP |
| 172 | select TRACER_SNAPSHOT |
| 173 | select TRACER_SNAPSHOT_PER_CPU_SWAP |
| 174 | help |
| 175 | This option measures the time spent in irqs-off critical |
| 176 | sections, with microsecond accuracy. |
| 177 | |
| 178 | The default measurement method is a maximum search, which is |
| 179 | disabled by default and can be runtime (re-)started |
| 180 | via: |
| 181 | |
| 182 | echo 0 > /sys/kernel/debug/tracing/tracing_max_latency |
| 183 | |
| 184 | (Note that kernel size and overhead increase with this option |
| 185 | enabled. This option and the preempt-off timing option can be |
| 186 | used together or separately.) |
| 187 | |
| 188 | config PREEMPT_TRACER |
| 189 | bool "Preemption-off Latency Tracer" |
| 190 | default n |
| 191 | depends on !ARCH_USES_GETTIMEOFFSET |
| 192 | depends on PREEMPT |
| 193 | select GENERIC_TRACER |
| 194 | select TRACER_MAX_TRACE |
| 195 | select RING_BUFFER_ALLOW_SWAP |
| 196 | select TRACER_SNAPSHOT |
| 197 | select TRACER_SNAPSHOT_PER_CPU_SWAP |
| 198 | help |
| 199 | This option measures the time spent in preemption-off critical |
| 200 | sections, with microsecond accuracy. |
| 201 | |
| 202 | The default measurement method is a maximum search, which is |
| 203 | disabled by default and can be runtime (re-)started |
| 204 | via: |
| 205 | |
| 206 | echo 0 > /sys/kernel/debug/tracing/tracing_max_latency |
| 207 | |
| 208 | (Note that kernel size and overhead increase with this option |
| 209 | enabled. This option and the irqs-off timing option can be |
| 210 | used together or separately.) |
| 211 | |
| 212 | config SCHED_TRACER |
| 213 | bool "Scheduling Latency Tracer" |
| 214 | select GENERIC_TRACER |
| 215 | select CONTEXT_SWITCH_TRACER |
| 216 | select TRACER_MAX_TRACE |
| 217 | select TRACER_SNAPSHOT |
| 218 | help |
| 219 | This tracer tracks the latency of the highest priority task |
| 220 | to be scheduled in, starting from the point it has woken up. |
| 221 | |
| 222 | config HWLAT_TRACER |
| 223 | bool "Tracer to detect hardware latencies (like SMIs)" |
| 224 | select GENERIC_TRACER |
| 225 | help |
| 226 | This tracer, when enabled will create one or more kernel threads, |
| 227 | depening on what the cpumask file is set to, which each thread |
| 228 | spinning in a loop looking for interruptions caused by |
| 229 | something other than the kernel. For example, if a |
| 230 | System Management Interrupt (SMI) takes a noticeable amount of |
| 231 | time, this tracer will detect it. This is useful for testing |
| 232 | if a system is reliable for Real Time tasks. |
| 233 | |
| 234 | Some files are created in the tracing directory when this |
| 235 | is enabled: |
| 236 | |
| 237 | hwlat_detector/width - time in usecs for how long to spin for |
| 238 | hwlat_detector/window - time in usecs between the start of each |
| 239 | iteration |
| 240 | |
| 241 | A kernel thread is created that will spin with interrupts disabled |
| 242 | for "width" microseconds in every "widow" cycle. It will not spin |
| 243 | for "window - width" microseconds, where the system can |
| 244 | continue to operate. |
| 245 | |
| 246 | The output will appear in the trace and trace_pipe files. |
| 247 | |
| 248 | When the tracer is not running, it has no affect on the system, |
| 249 | but when it is running, it can cause the system to be |
| 250 | periodically non responsive. Do not run this tracer on a |
| 251 | production system. |
| 252 | |
| 253 | To enable this tracer, echo in "hwlat" into the current_tracer |
| 254 | file. Every time a latency is greater than tracing_thresh, it will |
| 255 | be recorded into the ring buffer. |
| 256 | |
| 257 | config ENABLE_DEFAULT_TRACERS |
| 258 | bool "Trace process context switches and events" |
| 259 | depends on !GENERIC_TRACER |
| 260 | select TRACING |
| 261 | help |
| 262 | This tracer hooks to various trace points in the kernel, |
| 263 | allowing the user to pick and choose which trace point they |
| 264 | want to trace. It also includes the sched_switch tracer plugin. |
| 265 | |
| 266 | config FTRACE_SYSCALLS |
| 267 | bool "Trace syscalls" |
| 268 | depends on HAVE_SYSCALL_TRACEPOINTS |
| 269 | select GENERIC_TRACER |
| 270 | select KALLSYMS |
| 271 | help |
| 272 | Basic tracer to catch the syscall entry and exit events. |
| 273 | |
| 274 | config TRACER_SNAPSHOT |
| 275 | bool "Create a snapshot trace buffer" |
| 276 | select TRACER_MAX_TRACE |
| 277 | help |
| 278 | Allow tracing users to take snapshot of the current buffer using the |
| 279 | ftrace interface, e.g.: |
| 280 | |
| 281 | echo 1 > /sys/kernel/debug/tracing/snapshot |
| 282 | cat snapshot |
| 283 | |
| 284 | config TRACER_SNAPSHOT_PER_CPU_SWAP |
| 285 | bool "Allow snapshot to swap per CPU" |
| 286 | depends on TRACER_SNAPSHOT |
| 287 | select RING_BUFFER_ALLOW_SWAP |
| 288 | help |
| 289 | Allow doing a snapshot of a single CPU buffer instead of a |
| 290 | full swap (all buffers). If this is set, then the following is |
| 291 | allowed: |
| 292 | |
| 293 | echo 1 > /sys/kernel/debug/tracing/per_cpu/cpu2/snapshot |
| 294 | |
| 295 | After which, only the tracing buffer for CPU 2 was swapped with |
| 296 | the main tracing buffer, and the other CPU buffers remain the same. |
| 297 | |
| 298 | When this is enabled, this adds a little more overhead to the |
| 299 | trace recording, as it needs to add some checks to synchronize |
| 300 | recording with swaps. But this does not affect the performance |
| 301 | of the overall system. This is enabled by default when the preempt |
| 302 | or irq latency tracers are enabled, as those need to swap as well |
| 303 | and already adds the overhead (plus a lot more). |
| 304 | |
| 305 | config TRACE_BRANCH_PROFILING |
| 306 | bool |
| 307 | select GENERIC_TRACER |
| 308 | |
| 309 | choice |
| 310 | prompt "Branch Profiling" |
| 311 | default BRANCH_PROFILE_NONE |
| 312 | help |
| 313 | The branch profiling is a software profiler. It will add hooks |
| 314 | into the C conditionals to test which path a branch takes. |
| 315 | |
| 316 | The likely/unlikely profiler only looks at the conditions that |
| 317 | are annotated with a likely or unlikely macro. |
| 318 | |
| 319 | The "all branch" profiler will profile every if-statement in the |
| 320 | kernel. This profiler will also enable the likely/unlikely |
| 321 | profiler. |
| 322 | |
| 323 | Either of the above profilers adds a bit of overhead to the system. |
| 324 | If unsure, choose "No branch profiling". |
| 325 | |
| 326 | config BRANCH_PROFILE_NONE |
| 327 | bool "No branch profiling" |
| 328 | help |
| 329 | No branch profiling. Branch profiling adds a bit of overhead. |
| 330 | Only enable it if you want to analyse the branching behavior. |
| 331 | Otherwise keep it disabled. |
| 332 | |
| 333 | config PROFILE_ANNOTATED_BRANCHES |
| 334 | bool "Trace likely/unlikely profiler" |
| 335 | select TRACE_BRANCH_PROFILING |
| 336 | help |
| 337 | This tracer profiles all likely and unlikely macros |
| 338 | in the kernel. It will display the results in: |
| 339 | |
| 340 | /sys/kernel/debug/tracing/trace_stat/branch_annotated |
| 341 | |
| 342 | Note: this will add a significant overhead; only turn this |
| 343 | on if you need to profile the system's use of these macros. |
| 344 | |
| 345 | config PROFILE_ALL_BRANCHES |
| 346 | bool "Profile all if conditionals" |
| 347 | select TRACE_BRANCH_PROFILING |
| 348 | help |
| 349 | This tracer profiles all branch conditions. Every if () |
| 350 | taken in the kernel is recorded whether it hit or miss. |
| 351 | The results will be displayed in: |
| 352 | |
| 353 | /sys/kernel/debug/tracing/trace_stat/branch_all |
| 354 | |
| 355 | This option also enables the likely/unlikely profiler. |
| 356 | |
| 357 | This configuration, when enabled, will impose a great overhead |
| 358 | on the system. This should only be enabled when the system |
| 359 | is to be analyzed in much detail. |
| 360 | endchoice |
| 361 | |
| 362 | config TRACING_BRANCHES |
| 363 | bool |
| 364 | help |
| 365 | Selected by tracers that will trace the likely and unlikely |
| 366 | conditions. This prevents the tracers themselves from being |
| 367 | profiled. Profiling the tracing infrastructure can only happen |
| 368 | when the likelys and unlikelys are not being traced. |
| 369 | |
| 370 | config BRANCH_TRACER |
| 371 | bool "Trace likely/unlikely instances" |
| 372 | depends on TRACE_BRANCH_PROFILING |
| 373 | select TRACING_BRANCHES |
| 374 | help |
| 375 | This traces the events of likely and unlikely condition |
| 376 | calls in the kernel. The difference between this and the |
| 377 | "Trace likely/unlikely profiler" is that this is not a |
| 378 | histogram of the callers, but actually places the calling |
| 379 | events into a running trace buffer to see when and where the |
| 380 | events happened, as well as their results. |
| 381 | |
| 382 | Say N if unsure. |
| 383 | |
| 384 | config STACK_TRACER |
| 385 | bool "Trace max stack" |
| 386 | depends on HAVE_FUNCTION_TRACER |
| 387 | select FUNCTION_TRACER |
| 388 | select STACKTRACE |
| 389 | select KALLSYMS |
| 390 | help |
| 391 | This special tracer records the maximum stack footprint of the |
| 392 | kernel and displays it in /sys/kernel/debug/tracing/stack_trace. |
| 393 | |
| 394 | This tracer works by hooking into every function call that the |
| 395 | kernel executes, and keeping a maximum stack depth value and |
| 396 | stack-trace saved. If this is configured with DYNAMIC_FTRACE |
| 397 | then it will not have any overhead while the stack tracer |
| 398 | is disabled. |
| 399 | |
| 400 | To enable the stack tracer on bootup, pass in 'stacktrace' |
| 401 | on the kernel command line. |
| 402 | |
| 403 | The stack tracer can also be enabled or disabled via the |
| 404 | sysctl kernel.stack_tracer_enabled |
| 405 | |
| 406 | Say N if unsure. |
| 407 | |
| 408 | config BLK_DEV_IO_TRACE |
| 409 | bool "Support for tracing block IO actions" |
| 410 | depends on SYSFS |
| 411 | depends on BLOCK |
| 412 | select RELAY |
| 413 | select DEBUG_FS |
| 414 | select TRACEPOINTS |
| 415 | select GENERIC_TRACER |
| 416 | select STACKTRACE |
| 417 | help |
| 418 | Say Y here if you want to be able to trace the block layer actions |
| 419 | on a given queue. Tracing allows you to see any traffic happening |
| 420 | on a block device queue. For more information (and the userspace |
| 421 | support tools needed), fetch the blktrace tools from: |
| 422 | |
| 423 | git://git.kernel.dk/blktrace.git |
| 424 | |
| 425 | Tracing also is possible using the ftrace interface, e.g.: |
| 426 | |
| 427 | echo 1 > /sys/block/sda/sda1/trace/enable |
| 428 | echo blk > /sys/kernel/debug/tracing/current_tracer |
| 429 | cat /sys/kernel/debug/tracing/trace_pipe |
| 430 | |
| 431 | If unsure, say N. |
| 432 | |
| 433 | config KPROBE_EVENTS |
| 434 | depends on KPROBES |
| 435 | depends on HAVE_REGS_AND_STACK_ACCESS_API |
| 436 | bool "Enable kprobes-based dynamic events" |
| 437 | select TRACING |
| 438 | select PROBE_EVENTS |
| 439 | default y |
| 440 | help |
| 441 | This allows the user to add tracing events (similar to tracepoints) |
| 442 | on the fly via the ftrace interface. See |
| 443 | Documentation/trace/kprobetrace.txt for more details. |
| 444 | |
| 445 | Those events can be inserted wherever kprobes can probe, and record |
| 446 | various register and memory values. |
| 447 | |
| 448 | This option is also required by perf-probe subcommand of perf tools. |
| 449 | If you want to use perf tools, this option is strongly recommended. |
| 450 | |
| 451 | config UPROBE_EVENTS |
| 452 | bool "Enable uprobes-based dynamic events" |
| 453 | depends on ARCH_SUPPORTS_UPROBES |
| 454 | depends on MMU |
| 455 | depends on PERF_EVENTS |
| 456 | select UPROBES |
| 457 | select PROBE_EVENTS |
| 458 | select TRACING |
| 459 | default y |
| 460 | help |
| 461 | This allows the user to add tracing events on top of userspace |
| 462 | dynamic events (similar to tracepoints) on the fly via the trace |
| 463 | events interface. Those events can be inserted wherever uprobes |
| 464 | can probe, and record various registers. |
| 465 | This option is required if you plan to use perf-probe subcommand |
| 466 | of perf tools on user space applications. |
| 467 | |
| 468 | config BPF_EVENTS |
| 469 | depends on BPF_SYSCALL |
| 470 | depends on (KPROBE_EVENTS || UPROBE_EVENTS) && PERF_EVENTS |
| 471 | bool |
| 472 | default y |
| 473 | help |
| 474 | This allows the user to attach BPF programs to kprobe events. |
| 475 | |
| 476 | config PROBE_EVENTS |
| 477 | def_bool n |
| 478 | |
| 479 | config DYNAMIC_FTRACE |
| 480 | bool "enable/disable function tracing dynamically" |
| 481 | depends on FUNCTION_TRACER |
| 482 | depends on HAVE_DYNAMIC_FTRACE |
| 483 | default y |
| 484 | help |
| 485 | This option will modify all the calls to function tracing |
| 486 | dynamically (will patch them out of the binary image and |
| 487 | replace them with a No-Op instruction) on boot up. During |
| 488 | compile time, a table is made of all the locations that ftrace |
| 489 | can function trace, and this table is linked into the kernel |
| 490 | image. When this is enabled, functions can be individually |
| 491 | enabled, and the functions not enabled will not affect |
| 492 | performance of the system. |
| 493 | |
| 494 | See the files in /sys/kernel/debug/tracing: |
| 495 | available_filter_functions |
| 496 | set_ftrace_filter |
| 497 | set_ftrace_notrace |
| 498 | |
| 499 | This way a CONFIG_FUNCTION_TRACER kernel is slightly larger, but |
| 500 | otherwise has native performance as long as no tracing is active. |
| 501 | |
| 502 | config DYNAMIC_FTRACE_WITH_REGS |
| 503 | def_bool y |
| 504 | depends on DYNAMIC_FTRACE |
| 505 | depends on HAVE_DYNAMIC_FTRACE_WITH_REGS |
| 506 | |
| 507 | config FUNCTION_PROFILER |
| 508 | bool "Kernel function profiler" |
| 509 | depends on FUNCTION_TRACER |
| 510 | default n |
| 511 | help |
| 512 | This option enables the kernel function profiler. A file is created |
| 513 | in debugfs called function_profile_enabled which defaults to zero. |
| 514 | When a 1 is echoed into this file profiling begins, and when a |
| 515 | zero is entered, profiling stops. A "functions" file is created in |
| 516 | the trace_stats directory; this file shows the list of functions that |
| 517 | have been hit and their counters. |
| 518 | |
| 519 | If in doubt, say N. |
| 520 | |
| 521 | config FTRACE_MCOUNT_RECORD |
| 522 | def_bool y |
| 523 | depends on DYNAMIC_FTRACE |
| 524 | depends on HAVE_FTRACE_MCOUNT_RECORD |
| 525 | |
| 526 | config FTRACE_SELFTEST |
| 527 | bool |
| 528 | |
| 529 | config FTRACE_STARTUP_TEST |
| 530 | bool "Perform a startup test on ftrace" |
| 531 | depends on GENERIC_TRACER |
| 532 | select FTRACE_SELFTEST |
| 533 | help |
| 534 | This option performs a series of startup tests on ftrace. On bootup |
| 535 | a series of tests are made to verify that the tracer is |
| 536 | functioning properly. It will do tests on all the configured |
| 537 | tracers of ftrace. |
| 538 | |
| 539 | config EVENT_TRACE_TEST_SYSCALLS |
| 540 | bool "Run selftest on syscall events" |
| 541 | depends on FTRACE_STARTUP_TEST |
| 542 | help |
| 543 | This option will also enable testing every syscall event. |
| 544 | It only enables the event and disables it and runs various loads |
| 545 | with the event enabled. This adds a bit more time for kernel boot |
| 546 | up since it runs this on every system call defined. |
| 547 | |
| 548 | TBD - enable a way to actually call the syscalls as we test their |
| 549 | events |
| 550 | |
| 551 | config MMIOTRACE |
| 552 | bool "Memory mapped IO tracing" |
| 553 | depends on HAVE_MMIOTRACE_SUPPORT && PCI |
| 554 | select GENERIC_TRACER |
| 555 | help |
| 556 | Mmiotrace traces Memory Mapped I/O access and is meant for |
| 557 | debugging and reverse engineering. It is called from the ioremap |
| 558 | implementation and works via page faults. Tracing is disabled by |
| 559 | default and can be enabled at run-time. |
| 560 | |
| 561 | See Documentation/trace/mmiotrace.txt. |
| 562 | If you are not helping to develop drivers, say N. |
| 563 | |
| 564 | config TRACING_MAP |
| 565 | bool |
| 566 | depends on ARCH_HAVE_NMI_SAFE_CMPXCHG |
| 567 | help |
| 568 | tracing_map is a special-purpose lock-free map for tracing, |
| 569 | separated out as a stand-alone facility in order to allow it |
| 570 | to be shared between multiple tracers. It isn't meant to be |
| 571 | generally used outside of that context, and is normally |
| 572 | selected by tracers that use it. |
| 573 | |
| 574 | config HIST_TRIGGERS |
| 575 | bool "Histogram triggers" |
| 576 | depends on ARCH_HAVE_NMI_SAFE_CMPXCHG |
| 577 | select TRACING_MAP |
| 578 | select TRACING |
| 579 | default n |
| 580 | help |
| 581 | Hist triggers allow one or more arbitrary trace event fields |
| 582 | to be aggregated into hash tables and dumped to stdout by |
| 583 | reading a debugfs/tracefs file. They're useful for |
| 584 | gathering quick and dirty (though precise) summaries of |
| 585 | event activity as an initial guide for further investigation |
| 586 | using more advanced tools. |
| 587 | |
| 588 | See Documentation/trace/events.txt. |
| 589 | If in doubt, say N. |
| 590 | |
| 591 | config MMIOTRACE_TEST |
| 592 | tristate "Test module for mmiotrace" |
| 593 | depends on MMIOTRACE && m |
| 594 | help |
| 595 | This is a dumb module for testing mmiotrace. It is very dangerous |
| 596 | as it will write garbage to IO memory starting at a given address. |
| 597 | However, it should be safe to use on e.g. unused portion of VRAM. |
| 598 | |
| 599 | Say N, unless you absolutely know what you are doing. |
| 600 | |
| 601 | config TRACEPOINT_BENCHMARK |
| 602 | bool "Add tracepoint that benchmarks tracepoints" |
| 603 | help |
| 604 | This option creates the tracepoint "benchmark:benchmark_event". |
| 605 | When the tracepoint is enabled, it kicks off a kernel thread that |
| 606 | goes into an infinite loop (calling cond_sched() to let other tasks |
| 607 | run), and calls the tracepoint. Each iteration will record the time |
| 608 | it took to write to the tracepoint and the next iteration that |
| 609 | data will be passed to the tracepoint itself. That is, the tracepoint |
| 610 | will report the time it took to do the previous tracepoint. |
| 611 | The string written to the tracepoint is a static string of 128 bytes |
| 612 | to keep the time the same. The initial string is simply a write of |
| 613 | "START". The second string records the cold cache time of the first |
| 614 | write which is not added to the rest of the calculations. |
| 615 | |
| 616 | As it is a tight loop, it benchmarks as hot cache. That's fine because |
| 617 | we care most about hot paths that are probably in cache already. |
| 618 | |
| 619 | An example of the output: |
| 620 | |
| 621 | START |
| 622 | first=3672 [COLD CACHED] |
| 623 | last=632 first=3672 max=632 min=632 avg=316 std=446 std^2=199712 |
| 624 | last=278 first=3672 max=632 min=278 avg=303 std=316 std^2=100337 |
| 625 | last=277 first=3672 max=632 min=277 avg=296 std=258 std^2=67064 |
| 626 | last=273 first=3672 max=632 min=273 avg=292 std=224 std^2=50411 |
| 627 | last=273 first=3672 max=632 min=273 avg=288 std=200 std^2=40389 |
| 628 | last=281 first=3672 max=632 min=273 avg=287 std=183 std^2=33666 |
| 629 | |
| 630 | |
| 631 | config RING_BUFFER_BENCHMARK |
| 632 | tristate "Ring buffer benchmark stress tester" |
| 633 | depends on RING_BUFFER |
| 634 | help |
| 635 | This option creates a test to stress the ring buffer and benchmark it. |
| 636 | It creates its own ring buffer such that it will not interfere with |
| 637 | any other users of the ring buffer (such as ftrace). It then creates |
| 638 | a producer and consumer that will run for 10 seconds and sleep for |
| 639 | 10 seconds. Each interval it will print out the number of events |
| 640 | it recorded and give a rough estimate of how long each iteration took. |
| 641 | |
| 642 | It does not disable interrupts or raise its priority, so it may be |
| 643 | affected by processes that are running. |
| 644 | |
| 645 | If unsure, say N. |
| 646 | |
| 647 | config RING_BUFFER_STARTUP_TEST |
| 648 | bool "Ring buffer startup self test" |
| 649 | depends on RING_BUFFER |
| 650 | help |
| 651 | Run a simple self test on the ring buffer on boot up. Late in the |
| 652 | kernel boot sequence, the test will start that kicks off |
| 653 | a thread per cpu. Each thread will write various size events |
| 654 | into the ring buffer. Another thread is created to send IPIs |
| 655 | to each of the threads, where the IPI handler will also write |
| 656 | to the ring buffer, to test/stress the nesting ability. |
| 657 | If any anomalies are discovered, a warning will be displayed |
| 658 | and all ring buffers will be disabled. |
| 659 | |
| 660 | The test runs for 10 seconds. This will slow your boot time |
| 661 | by at least 10 more seconds. |
| 662 | |
| 663 | At the end of the test, statics and more checks are done. |
| 664 | It will output the stats of each per cpu buffer. What |
| 665 | was written, the sizes, what was read, what was lost, and |
| 666 | other similar details. |
| 667 | |
| 668 | If unsure, say N |
| 669 | |
| 670 | config TRACE_EVAL_MAP_FILE |
| 671 | bool "Show eval mappings for trace events" |
| 672 | depends on TRACING |
| 673 | help |
| 674 | The "print fmt" of the trace events will show the enum/sizeof names |
| 675 | instead of their values. This can cause problems for user space tools |
| 676 | that use this string to parse the raw data as user space does not know |
| 677 | how to convert the string to its value. |
| 678 | |
| 679 | To fix this, there's a special macro in the kernel that can be used |
| 680 | to convert an enum/sizeof into its value. If this macro is used, then |
| 681 | the print fmt strings will be converted to their values. |
| 682 | |
| 683 | If something does not get converted properly, this option can be |
| 684 | used to show what enums/sizeof the kernel tried to convert. |
| 685 | |
| 686 | This option is for debugging the conversions. A file is created |
| 687 | in the tracing directory called "eval_map" that will show the |
| 688 | names matched with their values and what trace event system they |
| 689 | belong too. |
| 690 | |
| 691 | Normally, the mapping of the strings to values will be freed after |
| 692 | boot up or module load. With this option, they will not be freed, as |
| 693 | they are needed for the "eval_map" file. Enabling this option will |
| 694 | increase the memory footprint of the running kernel. |
| 695 | |
| 696 | If unsure, say N |
| 697 | |
| 698 | config TRACING_EVENTS_GPIO |
| 699 | bool "Trace gpio events" |
| 700 | depends on GPIOLIB |
| 701 | default y |
| 702 | help |
| 703 | Enable tracing events for gpio subsystem |
| 704 | |
| 705 | endif # FTRACE |
| 706 | |
| 707 | endif # TRACING_SUPPORT |
| 708 | |