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