| 1 | # SPDX-License-Identifier: GPL-2.0-only |
| 2 | # |
| 3 | # Architectures that offer an FUNCTION_TRACER implementation should |
| 4 | # select HAVE_FUNCTION_TRACER: |
| 5 | # |
| 6 | |
| 7 | config USER_STACKTRACE_SUPPORT |
| 8 | bool |
| 9 | |
| 10 | config NOP_TRACER |
| 11 | bool |
| 12 | |
| 13 | config HAVE_RETHOOK |
| 14 | bool |
| 15 | |
| 16 | config RETHOOK |
| 17 | bool |
| 18 | depends on HAVE_RETHOOK |
| 19 | help |
| 20 | Enable generic return hooking feature. This is an internal |
| 21 | API, which will be used by other function-entry hooking |
| 22 | features like fprobe and kprobes. |
| 23 | |
| 24 | config HAVE_FUNCTION_TRACER |
| 25 | bool |
| 26 | help |
| 27 | See Documentation/trace/ftrace-design.rst |
| 28 | |
| 29 | config HAVE_FUNCTION_GRAPH_TRACER |
| 30 | bool |
| 31 | help |
| 32 | See Documentation/trace/ftrace-design.rst |
| 33 | |
| 34 | config HAVE_FUNCTION_GRAPH_FREGS |
| 35 | bool |
| 36 | |
| 37 | config HAVE_FTRACE_GRAPH_FUNC |
| 38 | bool |
| 39 | help |
| 40 | True if ftrace_graph_func() is defined. |
| 41 | |
| 42 | config HAVE_DYNAMIC_FTRACE |
| 43 | bool |
| 44 | help |
| 45 | See Documentation/trace/ftrace-design.rst |
| 46 | |
| 47 | config HAVE_DYNAMIC_FTRACE_WITH_REGS |
| 48 | bool |
| 49 | |
| 50 | config HAVE_DYNAMIC_FTRACE_WITH_DIRECT_CALLS |
| 51 | bool |
| 52 | |
| 53 | config HAVE_SINGLE_FTRACE_DIRECT_OPS |
| 54 | bool |
| 55 | |
| 56 | config HAVE_DYNAMIC_FTRACE_WITH_CALL_OPS |
| 57 | bool |
| 58 | |
| 59 | config HAVE_EXTRA_IPI_TRACEPOINTS |
| 60 | bool |
| 61 | help |
| 62 | For architectures that use ipi_raise, ipi_entry and ipi_exit |
| 63 | tracepoints. |
| 64 | |
| 65 | config HAVE_DYNAMIC_FTRACE_WITH_ARGS |
| 66 | bool |
| 67 | help |
| 68 | If this is set, then arguments and stack can be found from |
| 69 | the ftrace_regs passed into the function callback regs parameter |
| 70 | by default, even without setting the REGS flag in the ftrace_ops. |
| 71 | This allows for use of ftrace_regs_get_argument() and |
| 72 | ftrace_regs_get_stack_pointer(). |
| 73 | |
| 74 | config HAVE_FTRACE_REGS_HAVING_PT_REGS |
| 75 | bool |
| 76 | help |
| 77 | If this is set, ftrace_regs has pt_regs, thus it can convert to |
| 78 | pt_regs without allocating memory. |
| 79 | |
| 80 | config HAVE_DYNAMIC_FTRACE_NO_PATCHABLE |
| 81 | bool |
| 82 | help |
| 83 | If the architecture generates __patchable_function_entries sections |
| 84 | but does not want them included in the ftrace locations. |
| 85 | |
| 86 | config HAVE_DYNAMIC_FTRACE_WITH_JMP |
| 87 | bool |
| 88 | help |
| 89 | If the architecture supports to replace the __fentry__ with a |
| 90 | "jmp" instruction. |
| 91 | |
| 92 | config HAVE_SYSCALL_TRACEPOINTS |
| 93 | bool |
| 94 | help |
| 95 | See Documentation/trace/ftrace-design.rst |
| 96 | |
| 97 | config HAVE_FENTRY |
| 98 | bool |
| 99 | help |
| 100 | Arch supports the gcc options -pg with -mfentry |
| 101 | |
| 102 | config HAVE_NOP_MCOUNT |
| 103 | bool |
| 104 | help |
| 105 | Arch supports the gcc options -pg with -mrecord-mcount and -nop-mcount |
| 106 | |
| 107 | config HAVE_OBJTOOL_MCOUNT |
| 108 | bool |
| 109 | help |
| 110 | Arch supports objtool --mcount |
| 111 | |
| 112 | config HAVE_OBJTOOL_NOP_MCOUNT |
| 113 | bool |
| 114 | help |
| 115 | Arch supports the objtool options --mcount with --mnop. |
| 116 | An architecture can select this if it wants to enable nop'ing |
| 117 | of ftrace locations. |
| 118 | |
| 119 | config HAVE_C_RECORDMCOUNT |
| 120 | bool |
| 121 | help |
| 122 | C version of recordmcount available? |
| 123 | |
| 124 | config HAVE_BUILDTIME_MCOUNT_SORT |
| 125 | bool |
| 126 | help |
| 127 | An architecture selects this if it sorts the mcount_loc section |
| 128 | at build time. |
| 129 | |
| 130 | config BUILDTIME_MCOUNT_SORT |
| 131 | bool |
| 132 | default y |
| 133 | depends on HAVE_BUILDTIME_MCOUNT_SORT && DYNAMIC_FTRACE |
| 134 | help |
| 135 | Sort the mcount_loc section at build time. |
| 136 | |
| 137 | config TRACER_MAX_TRACE |
| 138 | bool |
| 139 | select TRACER_SNAPSHOT |
| 140 | |
| 141 | config TRACE_CLOCK |
| 142 | bool |
| 143 | |
| 144 | config RING_BUFFER |
| 145 | bool |
| 146 | select TRACE_CLOCK |
| 147 | select IRQ_WORK |
| 148 | |
| 149 | config EVENT_TRACING |
| 150 | select CONTEXT_SWITCH_TRACER |
| 151 | select GLOB |
| 152 | bool |
| 153 | |
| 154 | config CONTEXT_SWITCH_TRACER |
| 155 | bool |
| 156 | |
| 157 | config RING_BUFFER_ALLOW_SWAP |
| 158 | bool |
| 159 | help |
| 160 | Allow the use of ring_buffer_swap_cpu. |
| 161 | Adds a very slight overhead to tracing when enabled. |
| 162 | |
| 163 | config PREEMPTIRQ_TRACEPOINTS |
| 164 | bool |
| 165 | depends on TRACE_PREEMPT_TOGGLE || TRACE_IRQFLAGS |
| 166 | select TRACING |
| 167 | default y |
| 168 | help |
| 169 | Create preempt/irq toggle tracepoints if needed, so that other parts |
| 170 | of the kernel can use them to generate or add hooks to them. |
| 171 | |
| 172 | # All tracer options should select GENERIC_TRACER. For those options that are |
| 173 | # enabled by all tracers (context switch and event tracer) they select TRACING. |
| 174 | # This allows those options to appear when no other tracer is selected. But the |
| 175 | # options do not appear when something else selects it. We need the two options |
| 176 | # GENERIC_TRACER and TRACING to avoid circular dependencies to accomplish the |
| 177 | # hiding of the automatic options. |
| 178 | |
| 179 | config TRACING |
| 180 | bool |
| 181 | select RING_BUFFER |
| 182 | select STACKTRACE if STACKTRACE_SUPPORT |
| 183 | select TRACEPOINTS |
| 184 | select NOP_TRACER |
| 185 | select BINARY_PRINTF |
| 186 | select EVENT_TRACING |
| 187 | select TRACE_CLOCK |
| 188 | select NEED_TASKS_RCU |
| 189 | |
| 190 | config GENERIC_TRACER |
| 191 | bool |
| 192 | select TRACING |
| 193 | |
| 194 | # |
| 195 | # Minimum requirements an architecture has to meet for us to |
| 196 | # be able to offer generic tracing facilities: |
| 197 | # |
| 198 | config TRACING_SUPPORT |
| 199 | bool |
| 200 | depends on TRACE_IRQFLAGS_SUPPORT |
| 201 | depends on STACKTRACE_SUPPORT |
| 202 | default y |
| 203 | |
| 204 | menuconfig FTRACE |
| 205 | bool "Tracers" |
| 206 | depends on TRACING_SUPPORT |
| 207 | default y if DEBUG_KERNEL |
| 208 | help |
| 209 | Enable the kernel tracing infrastructure. |
| 210 | |
| 211 | if FTRACE |
| 212 | |
| 213 | config TRACEFS_AUTOMOUNT_DEPRECATED |
| 214 | bool "Automount tracefs on debugfs [DEPRECATED]" |
| 215 | depends on TRACING |
| 216 | default y |
| 217 | help |
| 218 | The tracing interface was moved from /sys/kernel/debug/tracing |
| 219 | to /sys/kernel/tracing in 2015, but the tracing file system |
| 220 | was still automounted in /sys/kernel/debug for backward |
| 221 | compatibility with tooling. |
| 222 | |
| 223 | The new interface has been around for more than 10 years and |
| 224 | the old debug mount will soon be removed. |
| 225 | |
| 226 | config BOOTTIME_TRACING |
| 227 | bool "Boot-time Tracing support" |
| 228 | depends on TRACING |
| 229 | select BOOT_CONFIG |
| 230 | help |
| 231 | Enable developer to setup ftrace subsystem via supplemental |
| 232 | kernel cmdline at boot time for debugging (tracing) driver |
| 233 | initialization and boot process. |
| 234 | |
| 235 | config FUNCTION_TRACER |
| 236 | bool "Kernel Function Tracer" |
| 237 | depends on HAVE_FUNCTION_TRACER |
| 238 | select KALLSYMS |
| 239 | select GENERIC_TRACER |
| 240 | select CONTEXT_SWITCH_TRACER |
| 241 | select GLOB |
| 242 | select NEED_TASKS_RCU |
| 243 | select TASKS_RUDE_RCU |
| 244 | help |
| 245 | Enable the kernel to trace every kernel function. This is done |
| 246 | by using a compiler feature to insert a small, 5-byte No-Operation |
| 247 | instruction at the beginning of every kernel function, which NOP |
| 248 | sequence is then dynamically patched into a tracer call when |
| 249 | tracing is enabled by the administrator. If it's runtime disabled |
| 250 | (the bootup default), then the overhead of the instructions is very |
| 251 | small and not measurable even in micro-benchmarks (at least on |
| 252 | x86, but may have impact on other architectures). |
| 253 | |
| 254 | config FUNCTION_GRAPH_TRACER |
| 255 | bool "Kernel Function Graph Tracer" |
| 256 | depends on HAVE_FUNCTION_GRAPH_TRACER |
| 257 | depends on FUNCTION_TRACER |
| 258 | depends on !X86_32 || !CC_OPTIMIZE_FOR_SIZE |
| 259 | default y |
| 260 | help |
| 261 | Enable the kernel to trace a function at both its return |
| 262 | and its entry. |
| 263 | Its first purpose is to trace the duration of functions and |
| 264 | draw a call graph for each thread with some information like |
| 265 | the return value. This is done by setting the current return |
| 266 | address on the current task structure into a stack of calls. |
| 267 | |
| 268 | config FUNCTION_GRAPH_RETVAL |
| 269 | bool "Kernel Function Graph Return Value" |
| 270 | depends on HAVE_FUNCTION_GRAPH_FREGS |
| 271 | depends on FUNCTION_GRAPH_TRACER |
| 272 | default n |
| 273 | help |
| 274 | Support recording and printing the function return value when |
| 275 | using function graph tracer. It can be helpful to locate functions |
| 276 | that return errors. This feature is off by default, and you can |
| 277 | enable it via the trace option funcgraph-retval. |
| 278 | See Documentation/trace/ftrace.rst |
| 279 | |
| 280 | config FUNCTION_GRAPH_RETADDR |
| 281 | bool "Kernel Function Graph Return Address" |
| 282 | depends on FUNCTION_GRAPH_TRACER |
| 283 | default n |
| 284 | help |
| 285 | Support recording and printing the function return address when |
| 286 | using function graph tracer. It can be helpful to locate code line that |
| 287 | the function is called. This feature is off by default, and you can |
| 288 | enable it via the trace option funcgraph-retaddr. |
| 289 | |
| 290 | config FUNCTION_TRACE_ARGS |
| 291 | bool |
| 292 | depends on PROBE_EVENTS_BTF_ARGS |
| 293 | default y |
| 294 | help |
| 295 | If supported with function argument access API and BTF, then |
| 296 | the function tracer and function graph tracer will support printing |
| 297 | of function arguments. This feature is off by default, and can be |
| 298 | enabled via the trace option func-args (for the function tracer) and |
| 299 | funcgraph-args (for the function graph tracer) |
| 300 | |
| 301 | config DYNAMIC_FTRACE |
| 302 | bool |
| 303 | depends on FUNCTION_TRACER |
| 304 | depends on HAVE_DYNAMIC_FTRACE |
| 305 | default y |
| 306 | help |
| 307 | This option will modify all the calls to function tracing |
| 308 | dynamically (will patch them out of the binary image and |
| 309 | replace them with a No-Op instruction) on boot up. During |
| 310 | compile time, a table is made of all the locations that ftrace |
| 311 | can function trace, and this table is linked into the kernel |
| 312 | image. When this is enabled, functions can be individually |
| 313 | enabled, and the functions not enabled will not affect |
| 314 | performance of the system. |
| 315 | |
| 316 | See the files in /sys/kernel/tracing: |
| 317 | available_filter_functions |
| 318 | set_ftrace_filter |
| 319 | set_ftrace_notrace |
| 320 | |
| 321 | This way a CONFIG_FUNCTION_TRACER kernel is slightly larger, but |
| 322 | otherwise has native performance as long as no tracing is active. |
| 323 | |
| 324 | config DYNAMIC_FTRACE_WITH_REGS |
| 325 | def_bool y |
| 326 | depends on DYNAMIC_FTRACE |
| 327 | depends on HAVE_DYNAMIC_FTRACE_WITH_REGS |
| 328 | |
| 329 | config DYNAMIC_FTRACE_WITH_DIRECT_CALLS |
| 330 | def_bool y |
| 331 | depends on DYNAMIC_FTRACE_WITH_REGS || DYNAMIC_FTRACE_WITH_ARGS |
| 332 | depends on HAVE_DYNAMIC_FTRACE_WITH_DIRECT_CALLS |
| 333 | |
| 334 | config DYNAMIC_FTRACE_WITH_CALL_OPS |
| 335 | def_bool y |
| 336 | depends on HAVE_DYNAMIC_FTRACE_WITH_CALL_OPS |
| 337 | |
| 338 | config DYNAMIC_FTRACE_WITH_ARGS |
| 339 | def_bool y |
| 340 | depends on DYNAMIC_FTRACE |
| 341 | depends on HAVE_DYNAMIC_FTRACE_WITH_ARGS |
| 342 | |
| 343 | config DYNAMIC_FTRACE_WITH_JMP |
| 344 | def_bool y |
| 345 | depends on DYNAMIC_FTRACE |
| 346 | depends on DYNAMIC_FTRACE_WITH_DIRECT_CALLS |
| 347 | depends on HAVE_DYNAMIC_FTRACE_WITH_JMP |
| 348 | |
| 349 | config FUNCTION_SELF_TRACING |
| 350 | bool "Function trace tracing code" |
| 351 | depends on FUNCTION_TRACER |
| 352 | help |
| 353 | Normally all the tracing code is set to notrace, where the function |
| 354 | tracer will ignore all the tracing functions. Sometimes it is useful |
| 355 | for debugging to trace some of the tracing infratructure itself. |
| 356 | Enable this to allow some of the tracing infrastructure to be traced |
| 357 | by the function tracer. Note, this will likely add noise to function |
| 358 | tracing if events and other tracing features are enabled along with |
| 359 | function tracing. |
| 360 | |
| 361 | If unsure, say N. |
| 362 | |
| 363 | config FPROBE |
| 364 | bool "Kernel Function Probe (fprobe)" |
| 365 | depends on HAVE_FUNCTION_GRAPH_FREGS && HAVE_FTRACE_GRAPH_FUNC |
| 366 | depends on DYNAMIC_FTRACE_WITH_ARGS |
| 367 | select FUNCTION_GRAPH_TRACER |
| 368 | default n |
| 369 | help |
| 370 | This option enables kernel function probe (fprobe) based on ftrace. |
| 371 | The fprobe is similar to kprobes, but probes only for kernel function |
| 372 | entries and exits. This also can probe multiple functions by one |
| 373 | fprobe. |
| 374 | |
| 375 | If unsure, say N. |
| 376 | |
| 377 | config FUNCTION_PROFILER |
| 378 | bool "Kernel function profiler" |
| 379 | depends on FUNCTION_TRACER |
| 380 | default n |
| 381 | help |
| 382 | This option enables the kernel function profiler. A file is created |
| 383 | in debugfs called function_profile_enabled which defaults to zero. |
| 384 | When a 1 is echoed into this file profiling begins, and when a |
| 385 | zero is entered, profiling stops. A "functions" file is created in |
| 386 | the trace_stat directory; this file shows the list of functions that |
| 387 | have been hit and their counters. |
| 388 | |
| 389 | If in doubt, say N. |
| 390 | |
| 391 | config STACK_TRACER |
| 392 | bool "Trace max stack" |
| 393 | depends on HAVE_FUNCTION_TRACER |
| 394 | select FUNCTION_TRACER |
| 395 | select STACKTRACE |
| 396 | select KALLSYMS |
| 397 | help |
| 398 | This special tracer records the maximum stack footprint of the |
| 399 | kernel and displays it in /sys/kernel/tracing/stack_trace. |
| 400 | |
| 401 | This tracer works by hooking into every function call that the |
| 402 | kernel executes, and keeping a maximum stack depth value and |
| 403 | stack-trace saved. If this is configured with DYNAMIC_FTRACE |
| 404 | then it will not have any overhead while the stack tracer |
| 405 | is disabled. |
| 406 | |
| 407 | To enable the stack tracer on bootup, pass in 'stacktrace' |
| 408 | on the kernel command line. |
| 409 | |
| 410 | The stack tracer can also be enabled or disabled via the |
| 411 | sysctl kernel.stack_tracer_enabled |
| 412 | |
| 413 | Say N if unsure. |
| 414 | |
| 415 | config TRACE_PREEMPT_TOGGLE |
| 416 | bool |
| 417 | help |
| 418 | Enables hooks which will be called when preemption is first disabled, |
| 419 | and last enabled. |
| 420 | |
| 421 | config IRQSOFF_TRACER |
| 422 | bool "Interrupts-off Latency Tracer" |
| 423 | default n |
| 424 | depends on TRACE_IRQFLAGS_SUPPORT |
| 425 | select TRACE_IRQFLAGS |
| 426 | select GENERIC_TRACER |
| 427 | select TRACER_MAX_TRACE |
| 428 | select RING_BUFFER_ALLOW_SWAP |
| 429 | select TRACER_SNAPSHOT_PER_CPU_SWAP |
| 430 | help |
| 431 | This option measures the time spent in irqs-off critical |
| 432 | sections, with microsecond accuracy. |
| 433 | |
| 434 | The default measurement method is a maximum search, which is |
| 435 | disabled by default and can be runtime (re-)started |
| 436 | via: |
| 437 | |
| 438 | echo 0 > /sys/kernel/tracing/tracing_max_latency |
| 439 | |
| 440 | (Note that kernel size and overhead increase with this option |
| 441 | enabled. This option and the preempt-off timing option can be |
| 442 | used together or separately.) |
| 443 | |
| 444 | config PREEMPT_TRACER |
| 445 | bool "Preemption-off Latency Tracer" |
| 446 | default n |
| 447 | depends on PREEMPTION |
| 448 | select GENERIC_TRACER |
| 449 | select TRACER_MAX_TRACE |
| 450 | select RING_BUFFER_ALLOW_SWAP |
| 451 | select TRACER_SNAPSHOT_PER_CPU_SWAP |
| 452 | select TRACE_PREEMPT_TOGGLE |
| 453 | help |
| 454 | This option measures the time spent in preemption-off critical |
| 455 | sections, with microsecond accuracy. |
| 456 | |
| 457 | The default measurement method is a maximum search, which is |
| 458 | disabled by default and can be runtime (re-)started |
| 459 | via: |
| 460 | |
| 461 | echo 0 > /sys/kernel/tracing/tracing_max_latency |
| 462 | |
| 463 | (Note that kernel size and overhead increase with this option |
| 464 | enabled. This option and the irqs-off timing option can be |
| 465 | used together or separately.) |
| 466 | |
| 467 | config SCHED_TRACER |
| 468 | bool "Scheduling Latency Tracer" |
| 469 | select GENERIC_TRACER |
| 470 | select CONTEXT_SWITCH_TRACER |
| 471 | select TRACER_MAX_TRACE |
| 472 | help |
| 473 | This tracer tracks the latency of the highest priority task |
| 474 | to be scheduled in, starting from the point it has woken up. |
| 475 | |
| 476 | config HWLAT_TRACER |
| 477 | bool "Tracer to detect hardware latencies (like SMIs)" |
| 478 | select GENERIC_TRACER |
| 479 | select TRACER_MAX_TRACE |
| 480 | help |
| 481 | This tracer, when enabled will create one or more kernel threads, |
| 482 | depending on what the cpumask file is set to, which each thread |
| 483 | spinning in a loop looking for interruptions caused by |
| 484 | something other than the kernel. For example, if a |
| 485 | System Management Interrupt (SMI) takes a noticeable amount of |
| 486 | time, this tracer will detect it. This is useful for testing |
| 487 | if a system is reliable for Real Time tasks. |
| 488 | |
| 489 | Some files are created in the tracing directory when this |
| 490 | is enabled: |
| 491 | |
| 492 | hwlat_detector/width - time in usecs for how long to spin for |
| 493 | hwlat_detector/window - time in usecs between the start of each |
| 494 | iteration |
| 495 | |
| 496 | A kernel thread is created that will spin with interrupts disabled |
| 497 | for "width" microseconds in every "window" cycle. It will not spin |
| 498 | for "window - width" microseconds, where the system can |
| 499 | continue to operate. |
| 500 | |
| 501 | The output will appear in the trace and trace_pipe files. |
| 502 | |
| 503 | When the tracer is not running, it has no affect on the system, |
| 504 | but when it is running, it can cause the system to be |
| 505 | periodically non responsive. Do not run this tracer on a |
| 506 | production system. |
| 507 | |
| 508 | To enable this tracer, echo in "hwlat" into the current_tracer |
| 509 | file. Every time a latency is greater than tracing_thresh, it will |
| 510 | be recorded into the ring buffer. |
| 511 | |
| 512 | config OSNOISE_TRACER |
| 513 | bool "OS Noise tracer" |
| 514 | select GENERIC_TRACER |
| 515 | select TRACER_MAX_TRACE |
| 516 | help |
| 517 | In the context of high-performance computing (HPC), the Operating |
| 518 | System Noise (osnoise) refers to the interference experienced by an |
| 519 | application due to activities inside the operating system. In the |
| 520 | context of Linux, NMIs, IRQs, SoftIRQs, and any other system thread |
| 521 | can cause noise to the system. Moreover, hardware-related jobs can |
| 522 | also cause noise, for example, via SMIs. |
| 523 | |
| 524 | The osnoise tracer leverages the hwlat_detector by running a similar |
| 525 | loop with preemption, SoftIRQs and IRQs enabled, thus allowing all |
| 526 | the sources of osnoise during its execution. The osnoise tracer takes |
| 527 | note of the entry and exit point of any source of interferences, |
| 528 | increasing a per-cpu interference counter. It saves an interference |
| 529 | counter for each source of interference. The interference counter for |
| 530 | NMI, IRQs, SoftIRQs, and threads is increased anytime the tool |
| 531 | observes these interferences' entry events. When a noise happens |
| 532 | without any interference from the operating system level, the |
| 533 | hardware noise counter increases, pointing to a hardware-related |
| 534 | noise. In this way, osnoise can account for any source of |
| 535 | interference. At the end of the period, the osnoise tracer prints |
| 536 | the sum of all noise, the max single noise, the percentage of CPU |
| 537 | available for the thread, and the counters for the noise sources. |
| 538 | |
| 539 | In addition to the tracer, a set of tracepoints were added to |
| 540 | facilitate the identification of the osnoise source. |
| 541 | |
| 542 | The output will appear in the trace and trace_pipe files. |
| 543 | |
| 544 | To enable this tracer, echo in "osnoise" into the current_tracer |
| 545 | file. |
| 546 | |
| 547 | config TIMERLAT_TRACER |
| 548 | bool "Timerlat tracer" |
| 549 | select OSNOISE_TRACER |
| 550 | select GENERIC_TRACER |
| 551 | help |
| 552 | The timerlat tracer aims to help the preemptive kernel developers |
| 553 | to find sources of wakeup latencies of real-time threads. |
| 554 | |
| 555 | The tracer creates a per-cpu kernel thread with real-time priority. |
| 556 | The tracer thread sets a periodic timer to wakeup itself, and goes |
| 557 | to sleep waiting for the timer to fire. At the wakeup, the thread |
| 558 | then computes a wakeup latency value as the difference between |
| 559 | the current time and the absolute time that the timer was set |
| 560 | to expire. |
| 561 | |
| 562 | The tracer prints two lines at every activation. The first is the |
| 563 | timer latency observed at the hardirq context before the |
| 564 | activation of the thread. The second is the timer latency observed |
| 565 | by the thread, which is the same level that cyclictest reports. The |
| 566 | ACTIVATION ID field serves to relate the irq execution to its |
| 567 | respective thread execution. |
| 568 | |
| 569 | The tracer is build on top of osnoise tracer, and the osnoise: |
| 570 | events can be used to trace the source of interference from NMI, |
| 571 | IRQs and other threads. It also enables the capture of the |
| 572 | stacktrace at the IRQ context, which helps to identify the code |
| 573 | path that can cause thread delay. |
| 574 | |
| 575 | config MMIOTRACE |
| 576 | bool "Memory mapped IO tracing" |
| 577 | depends on HAVE_MMIOTRACE_SUPPORT && PCI |
| 578 | select GENERIC_TRACER |
| 579 | help |
| 580 | Mmiotrace traces Memory Mapped I/O access and is meant for |
| 581 | debugging and reverse engineering. It is called from the ioremap |
| 582 | implementation and works via page faults. Tracing is disabled by |
| 583 | default and can be enabled at run-time. |
| 584 | |
| 585 | See Documentation/trace/mmiotrace.rst. |
| 586 | If you are not helping to develop drivers, say N. |
| 587 | |
| 588 | config ENABLE_DEFAULT_TRACERS |
| 589 | bool "Trace process context switches and events" |
| 590 | depends on !GENERIC_TRACER |
| 591 | select TRACING |
| 592 | help |
| 593 | This tracer hooks to various trace points in the kernel, |
| 594 | allowing the user to pick and choose which trace point they |
| 595 | want to trace. It also includes the sched_switch tracer plugin. |
| 596 | |
| 597 | config FTRACE_SYSCALLS |
| 598 | bool "Trace syscalls" |
| 599 | depends on HAVE_SYSCALL_TRACEPOINTS |
| 600 | select GENERIC_TRACER |
| 601 | select KALLSYMS |
| 602 | help |
| 603 | Basic tracer to catch the syscall entry and exit events. |
| 604 | |
| 605 | config TRACE_SYSCALL_BUF_SIZE_DEFAULT |
| 606 | int "System call user read max size" |
| 607 | range 0 165 |
| 608 | default 63 |
| 609 | depends on FTRACE_SYSCALLS |
| 610 | help |
| 611 | Some system call trace events will record the data from a user |
| 612 | space address that one of the parameters point to. The amount of |
| 613 | data per event is limited. That limit is set by this config and |
| 614 | this config also affects how much user space data perf can read. |
| 615 | |
| 616 | For a tracing instance, this size may be changed by writing into |
| 617 | its syscall_user_buf_size file. |
| 618 | |
| 619 | config TRACER_SNAPSHOT |
| 620 | bool "Create a snapshot trace buffer" |
| 621 | help |
| 622 | Allow tracing users to take snapshot of the current buffer using the |
| 623 | ftrace interface, e.g.: |
| 624 | |
| 625 | echo 1 > /sys/kernel/tracing/snapshot |
| 626 | cat snapshot |
| 627 | |
| 628 | Note, the latency tracers select this option. To disable it, |
| 629 | all the latency tracers need to be disabled. |
| 630 | |
| 631 | config TRACER_SNAPSHOT_PER_CPU_SWAP |
| 632 | bool "Allow snapshot to swap per CPU" |
| 633 | depends on TRACER_SNAPSHOT |
| 634 | select RING_BUFFER_ALLOW_SWAP |
| 635 | help |
| 636 | Allow doing a snapshot of a single CPU buffer instead of a |
| 637 | full swap (all buffers). If this is set, then the following is |
| 638 | allowed: |
| 639 | |
| 640 | echo 1 > /sys/kernel/tracing/per_cpu/cpu2/snapshot |
| 641 | |
| 642 | After which, only the tracing buffer for CPU 2 was swapped with |
| 643 | the main tracing buffer, and the other CPU buffers remain the same. |
| 644 | |
| 645 | When this is enabled, this adds a little more overhead to the |
| 646 | trace recording, as it needs to add some checks to synchronize |
| 647 | recording with swaps. But this does not affect the performance |
| 648 | of the overall system. This is enabled by default when the preempt |
| 649 | or irq latency tracers are enabled, as those need to swap as well |
| 650 | and already adds the overhead (plus a lot more). |
| 651 | |
| 652 | config TRACE_BRANCH_PROFILING |
| 653 | bool |
| 654 | select GENERIC_TRACER |
| 655 | |
| 656 | choice |
| 657 | prompt "Branch Profiling" |
| 658 | default BRANCH_PROFILE_NONE |
| 659 | help |
| 660 | The branch profiling is a software profiler. It will add hooks |
| 661 | into the C conditionals to test which path a branch takes. |
| 662 | |
| 663 | The likely/unlikely profiler only looks at the conditions that |
| 664 | are annotated with a likely or unlikely macro. |
| 665 | |
| 666 | The "all branch" profiler will profile every if-statement in the |
| 667 | kernel. This profiler will also enable the likely/unlikely |
| 668 | profiler. |
| 669 | |
| 670 | Either of the above profilers adds a bit of overhead to the system. |
| 671 | If unsure, choose "No branch profiling". |
| 672 | |
| 673 | config BRANCH_PROFILE_NONE |
| 674 | bool "No branch profiling" |
| 675 | help |
| 676 | No branch profiling. Branch profiling adds a bit of overhead. |
| 677 | Only enable it if you want to analyse the branching behavior. |
| 678 | Otherwise keep it disabled. |
| 679 | |
| 680 | config PROFILE_ANNOTATED_BRANCHES |
| 681 | bool "Trace likely/unlikely profiler" |
| 682 | select TRACE_BRANCH_PROFILING |
| 683 | help |
| 684 | This tracer profiles all likely and unlikely macros |
| 685 | in the kernel. It will display the results in: |
| 686 | |
| 687 | /sys/kernel/tracing/trace_stat/branch_annotated |
| 688 | |
| 689 | Note: this will add a significant overhead; only turn this |
| 690 | on if you need to profile the system's use of these macros. |
| 691 | |
| 692 | config PROFILE_ALL_BRANCHES |
| 693 | bool "Profile all if conditionals" if !FORTIFY_SOURCE |
| 694 | select TRACE_BRANCH_PROFILING |
| 695 | help |
| 696 | This tracer profiles all branch conditions. Every if () |
| 697 | taken in the kernel is recorded whether it hit or miss. |
| 698 | The results will be displayed in: |
| 699 | |
| 700 | /sys/kernel/tracing/trace_stat/branch_all |
| 701 | |
| 702 | This option also enables the likely/unlikely profiler. |
| 703 | |
| 704 | This configuration, when enabled, will impose a great overhead |
| 705 | on the system. This should only be enabled when the system |
| 706 | is to be analyzed in much detail. |
| 707 | endchoice |
| 708 | |
| 709 | config TRACING_BRANCHES |
| 710 | bool |
| 711 | help |
| 712 | Selected by tracers that will trace the likely and unlikely |
| 713 | conditions. This prevents the tracers themselves from being |
| 714 | profiled. Profiling the tracing infrastructure can only happen |
| 715 | when the likelys and unlikelys are not being traced. |
| 716 | |
| 717 | config BRANCH_TRACER |
| 718 | bool "Trace likely/unlikely instances" |
| 719 | depends on TRACE_BRANCH_PROFILING |
| 720 | select TRACING_BRANCHES |
| 721 | help |
| 722 | This traces the events of likely and unlikely condition |
| 723 | calls in the kernel. The difference between this and the |
| 724 | "Trace likely/unlikely profiler" is that this is not a |
| 725 | histogram of the callers, but actually places the calling |
| 726 | events into a running trace buffer to see when and where the |
| 727 | events happened, as well as their results. |
| 728 | |
| 729 | Say N if unsure. |
| 730 | |
| 731 | config BLK_DEV_IO_TRACE |
| 732 | bool "Support for tracing block IO actions" |
| 733 | depends on SYSFS |
| 734 | depends on BLOCK |
| 735 | select RELAY |
| 736 | select DEBUG_FS |
| 737 | select TRACEPOINTS |
| 738 | select GENERIC_TRACER |
| 739 | select STACKTRACE |
| 740 | help |
| 741 | Say Y here if you want to be able to trace the block layer actions |
| 742 | on a given queue. Tracing allows you to see any traffic happening |
| 743 | on a block device queue. For more information (and the userspace |
| 744 | support tools needed), fetch the blktrace tools from: |
| 745 | |
| 746 | git://git.kernel.dk/blktrace.git |
| 747 | |
| 748 | Tracing also is possible using the ftrace interface, e.g.: |
| 749 | |
| 750 | echo 1 > /sys/block/sda/sda1/trace/enable |
| 751 | echo blk > /sys/kernel/tracing/current_tracer |
| 752 | cat /sys/kernel/tracing/trace_pipe |
| 753 | |
| 754 | If unsure, say N. |
| 755 | |
| 756 | config FPROBE_EVENTS |
| 757 | depends on FPROBE |
| 758 | depends on HAVE_REGS_AND_STACK_ACCESS_API |
| 759 | bool "Enable fprobe-based dynamic events" |
| 760 | select TRACING |
| 761 | select PROBE_EVENTS |
| 762 | select DYNAMIC_EVENTS |
| 763 | default y |
| 764 | help |
| 765 | This allows user to add tracing events on the function entry and |
| 766 | exit via ftrace interface. The syntax is same as the kprobe events |
| 767 | and the kprobe events on function entry and exit will be |
| 768 | transparently converted to this fprobe events. |
| 769 | |
| 770 | config PROBE_EVENTS_BTF_ARGS |
| 771 | depends on HAVE_FUNCTION_ARG_ACCESS_API |
| 772 | depends on FPROBE_EVENTS || KPROBE_EVENTS |
| 773 | depends on DEBUG_INFO_BTF && BPF_SYSCALL |
| 774 | bool "Support BTF function arguments for probe events" |
| 775 | default y |
| 776 | help |
| 777 | The user can specify the arguments of the probe event using the names |
| 778 | of the arguments of the probed function, when the probe location is a |
| 779 | kernel function entry or a tracepoint. |
| 780 | This is available only if BTF (BPF Type Format) support is enabled. |
| 781 | |
| 782 | config PROBE_EVENTS_DUMP_FETCHARG |
| 783 | bool "Dump of dynamic probe event fetch-arguments" |
| 784 | depends on PROBE_EVENTS |
| 785 | default n |
| 786 | help |
| 787 | This shows the dump of fetch-arguments of dynamic probe events |
| 788 | alongside their event definitions in the dynamic_events file |
| 789 | as comment lines. This is useful to debug the probe events. |
| 790 | Since this exposes the raw values in the dynamic_events file, |
| 791 | it might be a security risk. Only enable it if you need to debug |
| 792 | probe events themselves. |
| 793 | |
| 794 | config KPROBE_EVENTS |
| 795 | depends on KPROBES |
| 796 | depends on HAVE_REGS_AND_STACK_ACCESS_API |
| 797 | bool "Enable kprobes-based dynamic events" |
| 798 | select TRACING |
| 799 | select PROBE_EVENTS |
| 800 | select DYNAMIC_EVENTS |
| 801 | default y |
| 802 | help |
| 803 | This allows the user to add tracing events (similar to tracepoints) |
| 804 | on the fly via the ftrace interface. See |
| 805 | Documentation/trace/kprobetrace.rst for more details. |
| 806 | |
| 807 | Those events can be inserted wherever kprobes can probe, and record |
| 808 | various register and memory values. |
| 809 | |
| 810 | This option is also required by perf-probe subcommand of perf tools. |
| 811 | If you want to use perf tools, this option is strongly recommended. |
| 812 | |
| 813 | config KPROBE_EVENTS_ON_NOTRACE |
| 814 | bool "Do NOT protect notrace function from kprobe events" |
| 815 | depends on KPROBE_EVENTS |
| 816 | depends on DYNAMIC_FTRACE |
| 817 | default n |
| 818 | help |
| 819 | This is only for the developers who want to debug ftrace itself |
| 820 | using kprobe events. |
| 821 | |
| 822 | If kprobes can use ftrace instead of breakpoint, ftrace related |
| 823 | functions are protected from kprobe-events to prevent an infinite |
| 824 | recursion or any unexpected execution path which leads to a kernel |
| 825 | crash. |
| 826 | |
| 827 | This option disables such protection and allows you to put kprobe |
| 828 | events on ftrace functions for debugging ftrace by itself. |
| 829 | Note that this might let you shoot yourself in the foot. |
| 830 | |
| 831 | If unsure, say N. |
| 832 | |
| 833 | config UPROBE_EVENTS |
| 834 | bool "Enable uprobes-based dynamic events" |
| 835 | depends on ARCH_SUPPORTS_UPROBES |
| 836 | depends on MMU |
| 837 | depends on PERF_EVENTS |
| 838 | select UPROBES |
| 839 | select PROBE_EVENTS |
| 840 | select DYNAMIC_EVENTS |
| 841 | select TRACING |
| 842 | default y |
| 843 | help |
| 844 | This allows the user to add tracing events on top of userspace |
| 845 | dynamic events (similar to tracepoints) on the fly via the trace |
| 846 | events interface. Those events can be inserted wherever uprobes |
| 847 | can probe, and record various registers. |
| 848 | This option is required if you plan to use perf-probe subcommand |
| 849 | of perf tools on user space applications. |
| 850 | |
| 851 | config EPROBE_EVENTS |
| 852 | bool "Enable event-based dynamic events" |
| 853 | depends on TRACING |
| 854 | depends on HAVE_REGS_AND_STACK_ACCESS_API |
| 855 | select PROBE_EVENTS |
| 856 | select DYNAMIC_EVENTS |
| 857 | default y |
| 858 | help |
| 859 | Eprobes are dynamic events that can be placed on other existing |
| 860 | events. It can be used to limit what fields are recorded in |
| 861 | an event or even dereference a field of an event. It can |
| 862 | convert the type of an event field. For example, turn an |
| 863 | address into a string. |
| 864 | |
| 865 | config BPF_EVENTS |
| 866 | depends on BPF_SYSCALL |
| 867 | depends on (KPROBE_EVENTS || UPROBE_EVENTS) && PERF_EVENTS |
| 868 | bool |
| 869 | default y |
| 870 | help |
| 871 | This allows the user to attach BPF programs to kprobe, uprobe, and |
| 872 | tracepoint events. |
| 873 | |
| 874 | config DYNAMIC_EVENTS |
| 875 | def_bool n |
| 876 | |
| 877 | config PROBE_EVENTS |
| 878 | def_bool n |
| 879 | |
| 880 | config BPF_KPROBE_OVERRIDE |
| 881 | bool "Enable BPF programs to override a kprobed function" |
| 882 | depends on BPF_EVENTS |
| 883 | depends on FUNCTION_ERROR_INJECTION |
| 884 | default n |
| 885 | help |
| 886 | Allows BPF to override the execution of a probed function and |
| 887 | set a different return value. This is used for error injection. |
| 888 | |
| 889 | config FTRACE_MCOUNT_USE_PATCHABLE_FUNCTION_ENTRY |
| 890 | bool |
| 891 | depends on DYNAMIC_FTRACE |
| 892 | |
| 893 | config FTRACE_MCOUNT_USE_CC |
| 894 | def_bool y |
| 895 | depends on $(cc-option,-mrecord-mcount) |
| 896 | depends on !FTRACE_MCOUNT_USE_PATCHABLE_FUNCTION_ENTRY |
| 897 | depends on DYNAMIC_FTRACE |
| 898 | |
| 899 | config FTRACE_MCOUNT_USE_OBJTOOL |
| 900 | def_bool y |
| 901 | depends on HAVE_OBJTOOL_MCOUNT |
| 902 | depends on !FTRACE_MCOUNT_USE_PATCHABLE_FUNCTION_ENTRY |
| 903 | depends on !FTRACE_MCOUNT_USE_CC |
| 904 | depends on DYNAMIC_FTRACE |
| 905 | select OBJTOOL |
| 906 | |
| 907 | config FTRACE_MCOUNT_USE_RECORDMCOUNT |
| 908 | def_bool y |
| 909 | depends on !FTRACE_MCOUNT_USE_PATCHABLE_FUNCTION_ENTRY |
| 910 | depends on !FTRACE_MCOUNT_USE_CC |
| 911 | depends on !FTRACE_MCOUNT_USE_OBJTOOL |
| 912 | depends on DYNAMIC_FTRACE |
| 913 | |
| 914 | config TRACING_MAP |
| 915 | bool |
| 916 | depends on ARCH_HAVE_NMI_SAFE_CMPXCHG |
| 917 | help |
| 918 | tracing_map is a special-purpose lock-free map for tracing, |
| 919 | separated out as a stand-alone facility in order to allow it |
| 920 | to be shared between multiple tracers. It isn't meant to be |
| 921 | generally used outside of that context, and is normally |
| 922 | selected by tracers that use it. |
| 923 | |
| 924 | config SYNTH_EVENTS |
| 925 | bool "Synthetic trace events" |
| 926 | select TRACING |
| 927 | select DYNAMIC_EVENTS |
| 928 | default n |
| 929 | help |
| 930 | Synthetic events are user-defined trace events that can be |
| 931 | used to combine data from other trace events or in fact any |
| 932 | data source. Synthetic events can be generated indirectly |
| 933 | via the trace() action of histogram triggers or directly |
| 934 | by way of an in-kernel API. |
| 935 | |
| 936 | See Documentation/trace/events.rst or |
| 937 | Documentation/trace/histogram.rst for details and examples. |
| 938 | |
| 939 | If in doubt, say N. |
| 940 | |
| 941 | config USER_EVENTS |
| 942 | bool "User trace events" |
| 943 | select TRACING |
| 944 | select DYNAMIC_EVENTS |
| 945 | help |
| 946 | User trace events are user-defined trace events that |
| 947 | can be used like an existing kernel trace event. User trace |
| 948 | events are generated by writing to a tracefs file. User |
| 949 | processes can determine if their tracing events should be |
| 950 | generated by registering a value and bit with the kernel |
| 951 | that reflects when it is enabled or not. |
| 952 | |
| 953 | See Documentation/trace/user_events.rst. |
| 954 | If in doubt, say N. |
| 955 | |
| 956 | config HIST_TRIGGERS |
| 957 | bool "Histogram triggers" |
| 958 | depends on ARCH_HAVE_NMI_SAFE_CMPXCHG |
| 959 | select TRACING_MAP |
| 960 | select TRACING |
| 961 | select DYNAMIC_EVENTS |
| 962 | select SYNTH_EVENTS |
| 963 | default n |
| 964 | help |
| 965 | Hist triggers allow one or more arbitrary trace event fields |
| 966 | to be aggregated into hash tables and dumped to stdout by |
| 967 | reading a debugfs/tracefs file. They're useful for |
| 968 | gathering quick and dirty (though precise) summaries of |
| 969 | event activity as an initial guide for further investigation |
| 970 | using more advanced tools. |
| 971 | |
| 972 | Inter-event tracing of quantities such as latencies is also |
| 973 | supported using hist triggers under this option. |
| 974 | |
| 975 | See Documentation/trace/histogram.rst. |
| 976 | If in doubt, say N. |
| 977 | |
| 978 | config TRACE_EVENT_INJECT |
| 979 | bool "Trace event injection" |
| 980 | depends on TRACING |
| 981 | help |
| 982 | Allow user-space to inject a specific trace event into the ring |
| 983 | buffer. This is mainly used for testing purpose. |
| 984 | |
| 985 | If unsure, say N. |
| 986 | |
| 987 | config TRACEPOINT_BENCHMARK |
| 988 | bool "Add tracepoint that benchmarks tracepoints" |
| 989 | help |
| 990 | This option creates the tracepoint "benchmark:benchmark_event". |
| 991 | When the tracepoint is enabled, it kicks off a kernel thread that |
| 992 | goes into an infinite loop (calling cond_resched() to let other tasks |
| 993 | run), and calls the tracepoint. Each iteration will record the time |
| 994 | it took to write to the tracepoint and the next iteration that |
| 995 | data will be passed to the tracepoint itself. That is, the tracepoint |
| 996 | will report the time it took to do the previous tracepoint. |
| 997 | The string written to the tracepoint is a static string of 128 bytes |
| 998 | to keep the time the same. The initial string is simply a write of |
| 999 | "START". The second string records the cold cache time of the first |
| 1000 | write which is not added to the rest of the calculations. |
| 1001 | |
| 1002 | As it is a tight loop, it benchmarks as hot cache. That's fine because |
| 1003 | we care most about hot paths that are probably in cache already. |
| 1004 | |
| 1005 | An example of the output: |
| 1006 | |
| 1007 | START |
| 1008 | first=3672 [COLD CACHED] |
| 1009 | last=632 first=3672 max=632 min=632 avg=316 std=446 std^2=199712 |
| 1010 | last=278 first=3672 max=632 min=278 avg=303 std=316 std^2=100337 |
| 1011 | last=277 first=3672 max=632 min=277 avg=296 std=258 std^2=67064 |
| 1012 | last=273 first=3672 max=632 min=273 avg=292 std=224 std^2=50411 |
| 1013 | last=273 first=3672 max=632 min=273 avg=288 std=200 std^2=40389 |
| 1014 | last=281 first=3672 max=632 min=273 avg=287 std=183 std^2=33666 |
| 1015 | |
| 1016 | |
| 1017 | config RING_BUFFER_BENCHMARK |
| 1018 | tristate "Ring buffer benchmark stress tester" |
| 1019 | depends on RING_BUFFER |
| 1020 | help |
| 1021 | This option creates a test to stress the ring buffer and benchmark it. |
| 1022 | It creates its own ring buffer such that it will not interfere with |
| 1023 | any other users of the ring buffer (such as ftrace). It then creates |
| 1024 | a producer and consumer that will run for 10 seconds and sleep for |
| 1025 | 10 seconds. Each interval it will print out the number of events |
| 1026 | it recorded and give a rough estimate of how long each iteration took. |
| 1027 | |
| 1028 | It does not disable interrupts or raise its priority, so it may be |
| 1029 | affected by processes that are running. |
| 1030 | |
| 1031 | If unsure, say N. |
| 1032 | |
| 1033 | config TRACE_EVAL_MAP_FILE |
| 1034 | bool "Show eval mappings for trace events" |
| 1035 | depends on TRACING |
| 1036 | help |
| 1037 | The "print fmt" of the trace events will show the enum/sizeof names |
| 1038 | instead of their values. This can cause problems for user space tools |
| 1039 | that use this string to parse the raw data as user space does not know |
| 1040 | how to convert the string to its value. |
| 1041 | |
| 1042 | To fix this, there's a special macro in the kernel that can be used |
| 1043 | to convert an enum/sizeof into its value. If this macro is used, then |
| 1044 | the print fmt strings will be converted to their values. |
| 1045 | |
| 1046 | If something does not get converted properly, this option can be |
| 1047 | used to show what enums/sizeof the kernel tried to convert. |
| 1048 | |
| 1049 | This option is for debugging the conversions. A file is created |
| 1050 | in the tracing directory called "eval_map" that will show the |
| 1051 | names matched with their values and what trace event system they |
| 1052 | belong too. |
| 1053 | |
| 1054 | Normally, the mapping of the strings to values will be freed after |
| 1055 | boot up or module load. With this option, they will not be freed, as |
| 1056 | they are needed for the "eval_map" file. Enabling this option will |
| 1057 | increase the memory footprint of the running kernel. |
| 1058 | |
| 1059 | If unsure, say N. |
| 1060 | |
| 1061 | config FTRACE_RECORD_RECURSION |
| 1062 | bool "Record functions that recurse in function tracing" |
| 1063 | depends on FUNCTION_TRACER |
| 1064 | help |
| 1065 | All callbacks that attach to the function tracing have some sort |
| 1066 | of protection against recursion. Even though the protection exists, |
| 1067 | it adds overhead. This option will create a file in the tracefs |
| 1068 | file system called "recursed_functions" that will list the functions |
| 1069 | that triggered a recursion. |
| 1070 | |
| 1071 | This will add more overhead to cases that have recursion. |
| 1072 | |
| 1073 | If unsure, say N |
| 1074 | |
| 1075 | config FTRACE_RECORD_RECURSION_SIZE |
| 1076 | int "Max number of recursed functions to record" |
| 1077 | default 128 |
| 1078 | depends on FTRACE_RECORD_RECURSION |
| 1079 | help |
| 1080 | This defines the limit of number of functions that can be |
| 1081 | listed in the "recursed_functions" file, that lists all |
| 1082 | the functions that caused a recursion to happen. |
| 1083 | This file can be reset, but the limit can not change in |
| 1084 | size at runtime. |
| 1085 | |
| 1086 | config FTRACE_VALIDATE_RCU_IS_WATCHING |
| 1087 | bool "Validate RCU is on during ftrace execution" |
| 1088 | depends on FUNCTION_TRACER |
| 1089 | depends on ARCH_WANTS_NO_INSTR |
| 1090 | help |
| 1091 | All callbacks that attach to the function tracing have some sort of |
| 1092 | protection against recursion. This option is only to verify that |
| 1093 | ftrace (and other users of ftrace_test_recursion_trylock()) are not |
| 1094 | called outside of RCU, as if they are, it can cause a race. But it |
| 1095 | also has a noticeable overhead when enabled. |
| 1096 | |
| 1097 | If unsure, say N |
| 1098 | |
| 1099 | config RING_BUFFER_RECORD_RECURSION |
| 1100 | bool "Record functions that recurse in the ring buffer" |
| 1101 | depends on FTRACE_RECORD_RECURSION |
| 1102 | # default y, because it is coupled with FTRACE_RECORD_RECURSION |
| 1103 | default y |
| 1104 | help |
| 1105 | The ring buffer has its own internal recursion. Although when |
| 1106 | recursion happens it won't cause harm because of the protection, |
| 1107 | but it does cause unwanted overhead. Enabling this option will |
| 1108 | place where recursion was detected into the ftrace "recursed_functions" |
| 1109 | file. |
| 1110 | |
| 1111 | This will add more overhead to cases that have recursion. |
| 1112 | |
| 1113 | config GCOV_PROFILE_FTRACE |
| 1114 | bool "Enable GCOV profiling on ftrace subsystem" |
| 1115 | depends on GCOV_KERNEL |
| 1116 | help |
| 1117 | Enable GCOV profiling on ftrace subsystem for checking |
| 1118 | which functions/lines are tested. |
| 1119 | |
| 1120 | If unsure, say N. |
| 1121 | |
| 1122 | Note that on a kernel compiled with this config, ftrace will |
| 1123 | run significantly slower. |
| 1124 | |
| 1125 | config FTRACE_SELFTEST |
| 1126 | bool |
| 1127 | |
| 1128 | config FTRACE_STARTUP_TEST |
| 1129 | bool "Perform a startup test on ftrace" |
| 1130 | depends on GENERIC_TRACER |
| 1131 | select FTRACE_SELFTEST |
| 1132 | help |
| 1133 | This option performs a series of startup tests on ftrace. On bootup |
| 1134 | a series of tests are made to verify that the tracer is |
| 1135 | functioning properly. It will do tests on all the configured |
| 1136 | tracers of ftrace. |
| 1137 | |
| 1138 | config EVENT_TRACE_STARTUP_TEST |
| 1139 | bool "Run selftest on trace events" |
| 1140 | depends on FTRACE_STARTUP_TEST |
| 1141 | default y |
| 1142 | help |
| 1143 | This option performs a test on all trace events in the system. |
| 1144 | It basically just enables each event and runs some code that |
| 1145 | will trigger events (not necessarily the event it enables) |
| 1146 | This may take some time run as there are a lot of events. |
| 1147 | |
| 1148 | config EVENT_TRACE_TEST_SYSCALLS |
| 1149 | bool "Run selftest on syscall events" |
| 1150 | depends on EVENT_TRACE_STARTUP_TEST |
| 1151 | help |
| 1152 | This option will also enable testing every syscall event. |
| 1153 | It only enables the event and disables it and runs various loads |
| 1154 | with the event enabled. This adds a bit more time for kernel boot |
| 1155 | up since it runs this on every system call defined. |
| 1156 | |
| 1157 | TBD - enable a way to actually call the syscalls as we test their |
| 1158 | events |
| 1159 | |
| 1160 | config FTRACE_SORT_STARTUP_TEST |
| 1161 | bool "Verify compile time sorting of ftrace functions" |
| 1162 | depends on DYNAMIC_FTRACE |
| 1163 | depends on BUILDTIME_MCOUNT_SORT |
| 1164 | help |
| 1165 | Sorting of the mcount_loc sections that is used to find the |
| 1166 | where the ftrace knows where to patch functions for tracing |
| 1167 | and other callbacks is done at compile time. But if the sort |
| 1168 | is not done correctly, it will cause non-deterministic failures. |
| 1169 | When this is set, the sorted sections will be verified that they |
| 1170 | are in deed sorted and will warn if they are not. |
| 1171 | |
| 1172 | If unsure, say N |
| 1173 | |
| 1174 | config RING_BUFFER_STARTUP_TEST |
| 1175 | bool "Ring buffer startup self test" |
| 1176 | depends on RING_BUFFER |
| 1177 | help |
| 1178 | Run a simple self test on the ring buffer on boot up. Late in the |
| 1179 | kernel boot sequence, the test will start that kicks off |
| 1180 | a thread per cpu. Each thread will write various size events |
| 1181 | into the ring buffer. Another thread is created to send IPIs |
| 1182 | to each of the threads, where the IPI handler will also write |
| 1183 | to the ring buffer, to test/stress the nesting ability. |
| 1184 | If any anomalies are discovered, a warning will be displayed |
| 1185 | and all ring buffers will be disabled. |
| 1186 | |
| 1187 | The test runs for 10 seconds. This will slow your boot time |
| 1188 | by at least 10 more seconds. |
| 1189 | |
| 1190 | At the end of the test, statistics and more checks are done. |
| 1191 | It will output the stats of each per cpu buffer: What |
| 1192 | was written, the sizes, what was read, what was lost, and |
| 1193 | other similar details. |
| 1194 | |
| 1195 | If unsure, say N |
| 1196 | |
| 1197 | config RING_BUFFER_VALIDATE_TIME_DELTAS |
| 1198 | bool "Verify ring buffer time stamp deltas" |
| 1199 | depends on RING_BUFFER |
| 1200 | help |
| 1201 | This will audit the time stamps on the ring buffer sub |
| 1202 | buffer to make sure that all the time deltas for the |
| 1203 | events on a sub buffer matches the current time stamp. |
| 1204 | This audit is performed for every event that is not |
| 1205 | interrupted, or interrupting another event. A check |
| 1206 | is also made when traversing sub buffers to make sure |
| 1207 | that all the deltas on the previous sub buffer do not |
| 1208 | add up to be greater than the current time stamp. |
| 1209 | |
| 1210 | NOTE: This adds significant overhead to recording of events, |
| 1211 | and should only be used to test the logic of the ring buffer. |
| 1212 | Do not use it on production systems. |
| 1213 | |
| 1214 | Only say Y if you understand what this does, and you |
| 1215 | still want it enabled. Otherwise say N |
| 1216 | |
| 1217 | config RING_BUFFER_PERSISTENT_INJECT |
| 1218 | bool "Enable persistent ring buffer error injection test" |
| 1219 | depends on RING_BUFFER |
| 1220 | help |
| 1221 | This option will have the kernel check if the persistent ring |
| 1222 | buffer is named "ptracingtest". and if so, it will corrupt some |
| 1223 | of its pages on a kernel panic. This is used to test if the |
| 1224 | persistent ring buffer can recover from some of its sub-buffers |
| 1225 | being corrupted. |
| 1226 | To use this, boot a kernel with a "ptracingtest" persistent |
| 1227 | ring buffer, e.g. |
| 1228 | |
| 1229 | reserve_mem=20M:2M:trace trace_instance=ptracingtest@trace panic=1 |
| 1230 | |
| 1231 | And after the 1st boot, run the following commands: |
| 1232 | |
| 1233 | cd /sys/kernel/tracing/instances/ptracingtest |
| 1234 | echo 1 > events/enable |
| 1235 | echo 1 > tracing_on |
| 1236 | sleep 3 |
| 1237 | echo c > /proc/sysrq-trigger |
| 1238 | |
| 1239 | After the panic message, the kernel will reboot and will show |
| 1240 | the test results in the console output. |
| 1241 | |
| 1242 | Note that events for the test ring buffer needs to be enabled |
| 1243 | prior to crashing the kernel so that the ring buffer has content |
| 1244 | that the test will corrupt. |
| 1245 | As the test will corrupt events in the "ptracingtest" persistent |
| 1246 | ring buffer, it should not be used for any other purpose other |
| 1247 | than this test. |
| 1248 | |
| 1249 | If unsure, say N |
| 1250 | |
| 1251 | config MMIOTRACE_TEST |
| 1252 | tristate "Test module for mmiotrace" |
| 1253 | depends on MMIOTRACE && m |
| 1254 | help |
| 1255 | This is a dumb module for testing mmiotrace. It is very dangerous |
| 1256 | as it will write garbage to IO memory starting at a given address. |
| 1257 | However, it should be safe to use on e.g. unused portion of VRAM. |
| 1258 | |
| 1259 | Say N, unless you absolutely know what you are doing. |
| 1260 | |
| 1261 | config PREEMPTIRQ_DELAY_TEST |
| 1262 | tristate "Test module to create a preempt / IRQ disable delay thread to test latency tracers" |
| 1263 | depends on m |
| 1264 | help |
| 1265 | Select this option to build a test module that can help test latency |
| 1266 | tracers by executing a preempt or irq disable section with a user |
| 1267 | configurable delay. The module busy waits for the duration of the |
| 1268 | critical section. |
| 1269 | |
| 1270 | For example, the following invocation generates a burst of three |
| 1271 | irq-disabled critical sections for 500us: |
| 1272 | modprobe preemptirq_delay_test test_mode=irq delay=500 burst_size=3 |
| 1273 | |
| 1274 | What's more, if you want to attach the test on the cpu which the latency |
| 1275 | tracer is running on, specify cpu_affinity=cpu_num at the end of the |
| 1276 | command. |
| 1277 | |
| 1278 | If unsure, say N |
| 1279 | |
| 1280 | config SYNTH_EVENT_GEN_TEST |
| 1281 | tristate "Test module for in-kernel synthetic event generation" |
| 1282 | depends on SYNTH_EVENTS && m |
| 1283 | help |
| 1284 | This option creates a test module to check the base |
| 1285 | functionality of in-kernel synthetic event definition and |
| 1286 | generation. |
| 1287 | |
| 1288 | To test, insert the module, and then check the trace buffer |
| 1289 | for the generated sample events. |
| 1290 | |
| 1291 | If unsure, say N. |
| 1292 | |
| 1293 | config KPROBE_EVENT_GEN_TEST |
| 1294 | tristate "Test module for in-kernel kprobe event generation" |
| 1295 | depends on KPROBE_EVENTS && m |
| 1296 | help |
| 1297 | This option creates a test module to check the base |
| 1298 | functionality of in-kernel kprobe event definition. |
| 1299 | |
| 1300 | To test, insert the module, and then check the trace buffer |
| 1301 | for the generated kprobe events. |
| 1302 | |
| 1303 | If unsure, say N. |
| 1304 | |
| 1305 | config HIST_TRIGGERS_DEBUG |
| 1306 | bool "Hist trigger debug support" |
| 1307 | depends on HIST_TRIGGERS |
| 1308 | help |
| 1309 | Add "hist_debug" file for each event, which when read will |
| 1310 | dump out a bunch of internal details about the hist triggers |
| 1311 | defined on that event. |
| 1312 | |
| 1313 | The hist_debug file serves a couple of purposes: |
| 1314 | |
| 1315 | - Helps developers verify that nothing is broken. |
| 1316 | |
| 1317 | - Provides educational information to support the details |
| 1318 | of the hist trigger internals as described by |
| 1319 | Documentation/trace/histogram-design.rst. |
| 1320 | |
| 1321 | The hist_debug output only covers the data structures |
| 1322 | related to the histogram definitions themselves and doesn't |
| 1323 | display the internals of map buckets or variable values of |
| 1324 | running histograms. |
| 1325 | |
| 1326 | If unsure, say N. |
| 1327 | |
| 1328 | source "kernel/trace/rv/Kconfig" |
| 1329 | |
| 1330 | config TRACE_REMOTE |
| 1331 | bool |
| 1332 | |
| 1333 | config SIMPLE_RING_BUFFER |
| 1334 | bool |
| 1335 | |
| 1336 | config TRACE_REMOTE_TEST |
| 1337 | tristate "Test module for remote tracing" |
| 1338 | select TRACE_REMOTE |
| 1339 | select SIMPLE_RING_BUFFER |
| 1340 | help |
| 1341 | This trace remote includes a ring-buffer writer implementation using |
| 1342 | "simple_ring_buffer". This is solely intending for testing. |
| 1343 | |
| 1344 | endif # FTRACE |