1 # SPDX-License-Identifier: GPL-2.0-only
3 # Architectures that offer an FUNCTION_TRACER implementation should
4 # select HAVE_FUNCTION_TRACER:
7 config USER_STACKTRACE_SUPPORT
13 config HAVE_FUNCTION_TRACER
16 See Documentation/trace/ftrace-design.rst
18 config HAVE_FUNCTION_GRAPH_TRACER
21 See Documentation/trace/ftrace-design.rst
23 config HAVE_DYNAMIC_FTRACE
26 See Documentation/trace/ftrace-design.rst
28 config HAVE_DYNAMIC_FTRACE_WITH_REGS
31 config HAVE_DYNAMIC_FTRACE_WITH_DIRECT_CALLS
34 config HAVE_DYNAMIC_FTRACE_WITH_ARGS
37 If this is set, then arguments and stack can be found from
38 the pt_regs passed into the function callback regs parameter
39 by default, even without setting the REGS flag in the ftrace_ops.
40 This allows for use of regs_get_kernel_argument() and
41 kernel_stack_pointer().
43 config HAVE_FTRACE_MCOUNT_RECORD
46 See Documentation/trace/ftrace-design.rst
48 config HAVE_SYSCALL_TRACEPOINTS
51 See Documentation/trace/ftrace-design.rst
56 Arch supports the gcc options -pg with -mfentry
58 config HAVE_NOP_MCOUNT
61 Arch supports the gcc options -pg with -mrecord-mcount and -nop-mcount
63 config HAVE_OBJTOOL_MCOUNT
66 Arch supports objtool --mcount
68 config HAVE_C_RECORDMCOUNT
71 C version of recordmcount available?
73 config TRACER_MAX_TRACE
85 select CONTEXT_SWITCH_TRACER
89 config CONTEXT_SWITCH_TRACER
92 config RING_BUFFER_ALLOW_SWAP
95 Allow the use of ring_buffer_swap_cpu.
96 Adds a very slight overhead to tracing when enabled.
98 config PREEMPTIRQ_TRACEPOINTS
100 depends on TRACE_PREEMPT_TOGGLE || TRACE_IRQFLAGS
104 Create preempt/irq toggle tracepoints if needed, so that other parts
105 of the kernel can use them to generate or add hooks to them.
107 # All tracer options should select GENERIC_TRACER. For those options that are
108 # enabled by all tracers (context switch and event tracer) they select TRACING.
109 # This allows those options to appear when no other tracer is selected. But the
110 # options do not appear when something else selects it. We need the two options
111 # GENERIC_TRACER and TRACING to avoid circular dependencies to accomplish the
112 # hiding of the automatic options.
117 select STACKTRACE if STACKTRACE_SUPPORT
124 config GENERIC_TRACER
129 # Minimum requirements an architecture has to meet for us to
130 # be able to offer generic tracing facilities:
132 config TRACING_SUPPORT
134 depends on TRACE_IRQFLAGS_SUPPORT
135 depends on STACKTRACE_SUPPORT
142 default y if DEBUG_KERNEL
144 Enable the kernel tracing infrastructure.
148 config BOOTTIME_TRACING
149 bool "Boot-time Tracing support"
153 Enable developer to setup ftrace subsystem via supplemental
154 kernel cmdline at boot time for debugging (tracing) driver
155 initialization and boot process.
157 config FUNCTION_TRACER
158 bool "Kernel Function Tracer"
159 depends on HAVE_FUNCTION_TRACER
161 select GENERIC_TRACER
162 select CONTEXT_SWITCH_TRACER
164 select TASKS_RCU if PREEMPTION
165 select TASKS_RUDE_RCU
167 Enable the kernel to trace every kernel function. This is done
168 by using a compiler feature to insert a small, 5-byte No-Operation
169 instruction at the beginning of every kernel function, which NOP
170 sequence is then dynamically patched into a tracer call when
171 tracing is enabled by the administrator. If it's runtime disabled
172 (the bootup default), then the overhead of the instructions is very
173 small and not measurable even in micro-benchmarks.
175 config FUNCTION_GRAPH_TRACER
176 bool "Kernel Function Graph Tracer"
177 depends on HAVE_FUNCTION_GRAPH_TRACER
178 depends on FUNCTION_TRACER
179 depends on !X86_32 || !CC_OPTIMIZE_FOR_SIZE
182 Enable the kernel to trace a function at both its return
184 Its first purpose is to trace the duration of functions and
185 draw a call graph for each thread with some information like
186 the return value. This is done by setting the current return
187 address on the current task structure into a stack of calls.
189 config DYNAMIC_FTRACE
190 bool "enable/disable function tracing dynamically"
191 depends on FUNCTION_TRACER
192 depends on HAVE_DYNAMIC_FTRACE
195 This option will modify all the calls to function tracing
196 dynamically (will patch them out of the binary image and
197 replace them with a No-Op instruction) on boot up. During
198 compile time, a table is made of all the locations that ftrace
199 can function trace, and this table is linked into the kernel
200 image. When this is enabled, functions can be individually
201 enabled, and the functions not enabled will not affect
202 performance of the system.
204 See the files in /sys/kernel/debug/tracing:
205 available_filter_functions
209 This way a CONFIG_FUNCTION_TRACER kernel is slightly larger, but
210 otherwise has native performance as long as no tracing is active.
212 config DYNAMIC_FTRACE_WITH_REGS
214 depends on DYNAMIC_FTRACE
215 depends on HAVE_DYNAMIC_FTRACE_WITH_REGS
217 config DYNAMIC_FTRACE_WITH_DIRECT_CALLS
219 depends on DYNAMIC_FTRACE_WITH_REGS
220 depends on HAVE_DYNAMIC_FTRACE_WITH_DIRECT_CALLS
222 config DYNAMIC_FTRACE_WITH_ARGS
224 depends on DYNAMIC_FTRACE
225 depends on HAVE_DYNAMIC_FTRACE_WITH_ARGS
227 config FUNCTION_PROFILER
228 bool "Kernel function profiler"
229 depends on FUNCTION_TRACER
232 This option enables the kernel function profiler. A file is created
233 in debugfs called function_profile_enabled which defaults to zero.
234 When a 1 is echoed into this file profiling begins, and when a
235 zero is entered, profiling stops. A "functions" file is created in
236 the trace_stat directory; this file shows the list of functions that
237 have been hit and their counters.
242 bool "Trace max stack"
243 depends on HAVE_FUNCTION_TRACER
244 select FUNCTION_TRACER
248 This special tracer records the maximum stack footprint of the
249 kernel and displays it in /sys/kernel/debug/tracing/stack_trace.
251 This tracer works by hooking into every function call that the
252 kernel executes, and keeping a maximum stack depth value and
253 stack-trace saved. If this is configured with DYNAMIC_FTRACE
254 then it will not have any overhead while the stack tracer
257 To enable the stack tracer on bootup, pass in 'stacktrace'
258 on the kernel command line.
260 The stack tracer can also be enabled or disabled via the
261 sysctl kernel.stack_tracer_enabled
265 config TRACE_PREEMPT_TOGGLE
268 Enables hooks which will be called when preemption is first disabled,
271 config IRQSOFF_TRACER
272 bool "Interrupts-off Latency Tracer"
274 depends on TRACE_IRQFLAGS_SUPPORT
275 select TRACE_IRQFLAGS
276 select GENERIC_TRACER
277 select TRACER_MAX_TRACE
278 select RING_BUFFER_ALLOW_SWAP
279 select TRACER_SNAPSHOT
280 select TRACER_SNAPSHOT_PER_CPU_SWAP
282 This option measures the time spent in irqs-off critical
283 sections, with microsecond accuracy.
285 The default measurement method is a maximum search, which is
286 disabled by default and can be runtime (re-)started
289 echo 0 > /sys/kernel/debug/tracing/tracing_max_latency
291 (Note that kernel size and overhead increase with this option
292 enabled. This option and the preempt-off timing option can be
293 used together or separately.)
295 config PREEMPT_TRACER
296 bool "Preemption-off Latency Tracer"
298 depends on PREEMPTION
299 select GENERIC_TRACER
300 select TRACER_MAX_TRACE
301 select RING_BUFFER_ALLOW_SWAP
302 select TRACER_SNAPSHOT
303 select TRACER_SNAPSHOT_PER_CPU_SWAP
304 select TRACE_PREEMPT_TOGGLE
306 This option measures the time spent in preemption-off critical
307 sections, with microsecond accuracy.
309 The default measurement method is a maximum search, which is
310 disabled by default and can be runtime (re-)started
313 echo 0 > /sys/kernel/debug/tracing/tracing_max_latency
315 (Note that kernel size and overhead increase with this option
316 enabled. This option and the irqs-off timing option can be
317 used together or separately.)
320 bool "Scheduling Latency Tracer"
321 select GENERIC_TRACER
322 select CONTEXT_SWITCH_TRACER
323 select TRACER_MAX_TRACE
324 select TRACER_SNAPSHOT
326 This tracer tracks the latency of the highest priority task
327 to be scheduled in, starting from the point it has woken up.
330 bool "Tracer to detect hardware latencies (like SMIs)"
331 select GENERIC_TRACER
333 This tracer, when enabled will create one or more kernel threads,
334 depending on what the cpumask file is set to, which each thread
335 spinning in a loop looking for interruptions caused by
336 something other than the kernel. For example, if a
337 System Management Interrupt (SMI) takes a noticeable amount of
338 time, this tracer will detect it. This is useful for testing
339 if a system is reliable for Real Time tasks.
341 Some files are created in the tracing directory when this
344 hwlat_detector/width - time in usecs for how long to spin for
345 hwlat_detector/window - time in usecs between the start of each
348 A kernel thread is created that will spin with interrupts disabled
349 for "width" microseconds in every "window" cycle. It will not spin
350 for "window - width" microseconds, where the system can
353 The output will appear in the trace and trace_pipe files.
355 When the tracer is not running, it has no affect on the system,
356 but when it is running, it can cause the system to be
357 periodically non responsive. Do not run this tracer on a
360 To enable this tracer, echo in "hwlat" into the current_tracer
361 file. Every time a latency is greater than tracing_thresh, it will
362 be recorded into the ring buffer.
365 bool "Memory mapped IO tracing"
366 depends on HAVE_MMIOTRACE_SUPPORT && PCI
367 select GENERIC_TRACER
369 Mmiotrace traces Memory Mapped I/O access and is meant for
370 debugging and reverse engineering. It is called from the ioremap
371 implementation and works via page faults. Tracing is disabled by
372 default and can be enabled at run-time.
374 See Documentation/trace/mmiotrace.rst.
375 If you are not helping to develop drivers, say N.
377 config ENABLE_DEFAULT_TRACERS
378 bool "Trace process context switches and events"
379 depends on !GENERIC_TRACER
382 This tracer hooks to various trace points in the kernel,
383 allowing the user to pick and choose which trace point they
384 want to trace. It also includes the sched_switch tracer plugin.
386 config FTRACE_SYSCALLS
387 bool "Trace syscalls"
388 depends on HAVE_SYSCALL_TRACEPOINTS
389 select GENERIC_TRACER
392 Basic tracer to catch the syscall entry and exit events.
394 config TRACER_SNAPSHOT
395 bool "Create a snapshot trace buffer"
396 select TRACER_MAX_TRACE
398 Allow tracing users to take snapshot of the current buffer using the
399 ftrace interface, e.g.:
401 echo 1 > /sys/kernel/debug/tracing/snapshot
404 config TRACER_SNAPSHOT_PER_CPU_SWAP
405 bool "Allow snapshot to swap per CPU"
406 depends on TRACER_SNAPSHOT
407 select RING_BUFFER_ALLOW_SWAP
409 Allow doing a snapshot of a single CPU buffer instead of a
410 full swap (all buffers). If this is set, then the following is
413 echo 1 > /sys/kernel/debug/tracing/per_cpu/cpu2/snapshot
415 After which, only the tracing buffer for CPU 2 was swapped with
416 the main tracing buffer, and the other CPU buffers remain the same.
418 When this is enabled, this adds a little more overhead to the
419 trace recording, as it needs to add some checks to synchronize
420 recording with swaps. But this does not affect the performance
421 of the overall system. This is enabled by default when the preempt
422 or irq latency tracers are enabled, as those need to swap as well
423 and already adds the overhead (plus a lot more).
425 config TRACE_BRANCH_PROFILING
427 select GENERIC_TRACER
430 prompt "Branch Profiling"
431 default BRANCH_PROFILE_NONE
433 The branch profiling is a software profiler. It will add hooks
434 into the C conditionals to test which path a branch takes.
436 The likely/unlikely profiler only looks at the conditions that
437 are annotated with a likely or unlikely macro.
439 The "all branch" profiler will profile every if-statement in the
440 kernel. This profiler will also enable the likely/unlikely
443 Either of the above profilers adds a bit of overhead to the system.
444 If unsure, choose "No branch profiling".
446 config BRANCH_PROFILE_NONE
447 bool "No branch profiling"
449 No branch profiling. Branch profiling adds a bit of overhead.
450 Only enable it if you want to analyse the branching behavior.
451 Otherwise keep it disabled.
453 config PROFILE_ANNOTATED_BRANCHES
454 bool "Trace likely/unlikely profiler"
455 select TRACE_BRANCH_PROFILING
457 This tracer profiles all likely and unlikely macros
458 in the kernel. It will display the results in:
460 /sys/kernel/debug/tracing/trace_stat/branch_annotated
462 Note: this will add a significant overhead; only turn this
463 on if you need to profile the system's use of these macros.
465 config PROFILE_ALL_BRANCHES
466 bool "Profile all if conditionals" if !FORTIFY_SOURCE
467 select TRACE_BRANCH_PROFILING
469 This tracer profiles all branch conditions. Every if ()
470 taken in the kernel is recorded whether it hit or miss.
471 The results will be displayed in:
473 /sys/kernel/debug/tracing/trace_stat/branch_all
475 This option also enables the likely/unlikely profiler.
477 This configuration, when enabled, will impose a great overhead
478 on the system. This should only be enabled when the system
479 is to be analyzed in much detail.
482 config TRACING_BRANCHES
485 Selected by tracers that will trace the likely and unlikely
486 conditions. This prevents the tracers themselves from being
487 profiled. Profiling the tracing infrastructure can only happen
488 when the likelys and unlikelys are not being traced.
491 bool "Trace likely/unlikely instances"
492 depends on TRACE_BRANCH_PROFILING
493 select TRACING_BRANCHES
495 This traces the events of likely and unlikely condition
496 calls in the kernel. The difference between this and the
497 "Trace likely/unlikely profiler" is that this is not a
498 histogram of the callers, but actually places the calling
499 events into a running trace buffer to see when and where the
500 events happened, as well as their results.
504 config BLK_DEV_IO_TRACE
505 bool "Support for tracing block IO actions"
511 select GENERIC_TRACER
514 Say Y here if you want to be able to trace the block layer actions
515 on a given queue. Tracing allows you to see any traffic happening
516 on a block device queue. For more information (and the userspace
517 support tools needed), fetch the blktrace tools from:
519 git://git.kernel.dk/blktrace.git
521 Tracing also is possible using the ftrace interface, e.g.:
523 echo 1 > /sys/block/sda/sda1/trace/enable
524 echo blk > /sys/kernel/debug/tracing/current_tracer
525 cat /sys/kernel/debug/tracing/trace_pipe
531 depends on HAVE_REGS_AND_STACK_ACCESS_API
532 bool "Enable kprobes-based dynamic events"
535 select DYNAMIC_EVENTS
538 This allows the user to add tracing events (similar to tracepoints)
539 on the fly via the ftrace interface. See
540 Documentation/trace/kprobetrace.rst for more details.
542 Those events can be inserted wherever kprobes can probe, and record
543 various register and memory values.
545 This option is also required by perf-probe subcommand of perf tools.
546 If you want to use perf tools, this option is strongly recommended.
548 config KPROBE_EVENTS_ON_NOTRACE
549 bool "Do NOT protect notrace function from kprobe events"
550 depends on KPROBE_EVENTS
551 depends on DYNAMIC_FTRACE
554 This is only for the developers who want to debug ftrace itself
557 If kprobes can use ftrace instead of breakpoint, ftrace related
558 functions are protected from kprobe-events to prevent an infinite
559 recursion or any unexpected execution path which leads to a kernel
562 This option disables such protection and allows you to put kprobe
563 events on ftrace functions for debugging ftrace by itself.
564 Note that this might let you shoot yourself in the foot.
569 bool "Enable uprobes-based dynamic events"
570 depends on ARCH_SUPPORTS_UPROBES
572 depends on PERF_EVENTS
575 select DYNAMIC_EVENTS
579 This allows the user to add tracing events on top of userspace
580 dynamic events (similar to tracepoints) on the fly via the trace
581 events interface. Those events can be inserted wherever uprobes
582 can probe, and record various registers.
583 This option is required if you plan to use perf-probe subcommand
584 of perf tools on user space applications.
587 depends on BPF_SYSCALL
588 depends on (KPROBE_EVENTS || UPROBE_EVENTS) && PERF_EVENTS
592 This allows the user to attach BPF programs to kprobe, uprobe, and
595 config DYNAMIC_EVENTS
601 config BPF_KPROBE_OVERRIDE
602 bool "Enable BPF programs to override a kprobed function"
603 depends on BPF_EVENTS
604 depends on FUNCTION_ERROR_INJECTION
607 Allows BPF to override the execution of a probed function and
608 set a different return value. This is used for error injection.
610 config FTRACE_MCOUNT_RECORD
612 depends on DYNAMIC_FTRACE
613 depends on HAVE_FTRACE_MCOUNT_RECORD
615 config FTRACE_MCOUNT_USE_PATCHABLE_FUNCTION_ENTRY
617 depends on FTRACE_MCOUNT_RECORD
619 config FTRACE_MCOUNT_USE_CC
621 depends on $(cc-option,-mrecord-mcount)
622 depends on !FTRACE_MCOUNT_USE_PATCHABLE_FUNCTION_ENTRY
623 depends on FTRACE_MCOUNT_RECORD
625 config FTRACE_MCOUNT_USE_OBJTOOL
627 depends on HAVE_OBJTOOL_MCOUNT
628 depends on !FTRACE_MCOUNT_USE_PATCHABLE_FUNCTION_ENTRY
629 depends on !FTRACE_MCOUNT_USE_CC
630 depends on FTRACE_MCOUNT_RECORD
632 config FTRACE_MCOUNT_USE_RECORDMCOUNT
634 depends on !FTRACE_MCOUNT_USE_PATCHABLE_FUNCTION_ENTRY
635 depends on !FTRACE_MCOUNT_USE_CC
636 depends on !FTRACE_MCOUNT_USE_OBJTOOL
637 depends on FTRACE_MCOUNT_RECORD
641 depends on ARCH_HAVE_NMI_SAFE_CMPXCHG
643 tracing_map is a special-purpose lock-free map for tracing,
644 separated out as a stand-alone facility in order to allow it
645 to be shared between multiple tracers. It isn't meant to be
646 generally used outside of that context, and is normally
647 selected by tracers that use it.
650 bool "Synthetic trace events"
652 select DYNAMIC_EVENTS
655 Synthetic events are user-defined trace events that can be
656 used to combine data from other trace events or in fact any
657 data source. Synthetic events can be generated indirectly
658 via the trace() action of histogram triggers or directly
659 by way of an in-kernel API.
661 See Documentation/trace/events.rst or
662 Documentation/trace/histogram.rst for details and examples.
667 bool "Histogram triggers"
668 depends on ARCH_HAVE_NMI_SAFE_CMPXCHG
671 select DYNAMIC_EVENTS
675 Hist triggers allow one or more arbitrary trace event fields
676 to be aggregated into hash tables and dumped to stdout by
677 reading a debugfs/tracefs file. They're useful for
678 gathering quick and dirty (though precise) summaries of
679 event activity as an initial guide for further investigation
680 using more advanced tools.
682 Inter-event tracing of quantities such as latencies is also
683 supported using hist triggers under this option.
685 See Documentation/trace/histogram.rst.
688 config TRACE_EVENT_INJECT
689 bool "Trace event injection"
692 Allow user-space to inject a specific trace event into the ring
693 buffer. This is mainly used for testing purpose.
697 config TRACEPOINT_BENCHMARK
698 bool "Add tracepoint that benchmarks tracepoints"
700 This option creates the tracepoint "benchmark:benchmark_event".
701 When the tracepoint is enabled, it kicks off a kernel thread that
702 goes into an infinite loop (calling cond_resched() to let other tasks
703 run), and calls the tracepoint. Each iteration will record the time
704 it took to write to the tracepoint and the next iteration that
705 data will be passed to the tracepoint itself. That is, the tracepoint
706 will report the time it took to do the previous tracepoint.
707 The string written to the tracepoint is a static string of 128 bytes
708 to keep the time the same. The initial string is simply a write of
709 "START". The second string records the cold cache time of the first
710 write which is not added to the rest of the calculations.
712 As it is a tight loop, it benchmarks as hot cache. That's fine because
713 we care most about hot paths that are probably in cache already.
715 An example of the output:
718 first=3672 [COLD CACHED]
719 last=632 first=3672 max=632 min=632 avg=316 std=446 std^2=199712
720 last=278 first=3672 max=632 min=278 avg=303 std=316 std^2=100337
721 last=277 first=3672 max=632 min=277 avg=296 std=258 std^2=67064
722 last=273 first=3672 max=632 min=273 avg=292 std=224 std^2=50411
723 last=273 first=3672 max=632 min=273 avg=288 std=200 std^2=40389
724 last=281 first=3672 max=632 min=273 avg=287 std=183 std^2=33666
727 config RING_BUFFER_BENCHMARK
728 tristate "Ring buffer benchmark stress tester"
729 depends on RING_BUFFER
731 This option creates a test to stress the ring buffer and benchmark it.
732 It creates its own ring buffer such that it will not interfere with
733 any other users of the ring buffer (such as ftrace). It then creates
734 a producer and consumer that will run for 10 seconds and sleep for
735 10 seconds. Each interval it will print out the number of events
736 it recorded and give a rough estimate of how long each iteration took.
738 It does not disable interrupts or raise its priority, so it may be
739 affected by processes that are running.
743 config TRACE_EVAL_MAP_FILE
744 bool "Show eval mappings for trace events"
747 The "print fmt" of the trace events will show the enum/sizeof names
748 instead of their values. This can cause problems for user space tools
749 that use this string to parse the raw data as user space does not know
750 how to convert the string to its value.
752 To fix this, there's a special macro in the kernel that can be used
753 to convert an enum/sizeof into its value. If this macro is used, then
754 the print fmt strings will be converted to their values.
756 If something does not get converted properly, this option can be
757 used to show what enums/sizeof the kernel tried to convert.
759 This option is for debugging the conversions. A file is created
760 in the tracing directory called "eval_map" that will show the
761 names matched with their values and what trace event system they
764 Normally, the mapping of the strings to values will be freed after
765 boot up or module load. With this option, they will not be freed, as
766 they are needed for the "eval_map" file. Enabling this option will
767 increase the memory footprint of the running kernel.
771 config FTRACE_RECORD_RECURSION
772 bool "Record functions that recurse in function tracing"
773 depends on FUNCTION_TRACER
775 All callbacks that attach to the function tracing have some sort
776 of protection against recursion. Even though the protection exists,
777 it adds overhead. This option will create a file in the tracefs
778 file system called "recursed_functions" that will list the functions
779 that triggered a recursion.
781 This will add more overhead to cases that have recursion.
785 config FTRACE_RECORD_RECURSION_SIZE
786 int "Max number of recursed functions to record"
788 depends on FTRACE_RECORD_RECURSION
790 This defines the limit of number of functions that can be
791 listed in the "recursed_functions" file, that lists all
792 the functions that caused a recursion to happen.
793 This file can be reset, but the limit can not change in
796 config RING_BUFFER_RECORD_RECURSION
797 bool "Record functions that recurse in the ring buffer"
798 depends on FTRACE_RECORD_RECURSION
799 # default y, because it is coupled with FTRACE_RECORD_RECURSION
802 The ring buffer has its own internal recursion. Although when
803 recursion happens it wont cause harm because of the protection,
804 but it does cause an unwanted overhead. Enabling this option will
805 place where recursion was detected into the ftrace "recursed_functions"
808 This will add more overhead to cases that have recursion.
810 config GCOV_PROFILE_FTRACE
811 bool "Enable GCOV profiling on ftrace subsystem"
812 depends on GCOV_KERNEL
814 Enable GCOV profiling on ftrace subsystem for checking
815 which functions/lines are tested.
819 Note that on a kernel compiled with this config, ftrace will
820 run significantly slower.
822 config FTRACE_SELFTEST
825 config FTRACE_STARTUP_TEST
826 bool "Perform a startup test on ftrace"
827 depends on GENERIC_TRACER
828 select FTRACE_SELFTEST
830 This option performs a series of startup tests on ftrace. On bootup
831 a series of tests are made to verify that the tracer is
832 functioning properly. It will do tests on all the configured
835 config EVENT_TRACE_STARTUP_TEST
836 bool "Run selftest on trace events"
837 depends on FTRACE_STARTUP_TEST
840 This option performs a test on all trace events in the system.
841 It basically just enables each event and runs some code that
842 will trigger events (not necessarily the event it enables)
843 This may take some time run as there are a lot of events.
845 config EVENT_TRACE_TEST_SYSCALLS
846 bool "Run selftest on syscall events"
847 depends on EVENT_TRACE_STARTUP_TEST
849 This option will also enable testing every syscall event.
850 It only enables the event and disables it and runs various loads
851 with the event enabled. This adds a bit more time for kernel boot
852 up since it runs this on every system call defined.
854 TBD - enable a way to actually call the syscalls as we test their
857 config RING_BUFFER_STARTUP_TEST
858 bool "Ring buffer startup self test"
859 depends on RING_BUFFER
861 Run a simple self test on the ring buffer on boot up. Late in the
862 kernel boot sequence, the test will start that kicks off
863 a thread per cpu. Each thread will write various size events
864 into the ring buffer. Another thread is created to send IPIs
865 to each of the threads, where the IPI handler will also write
866 to the ring buffer, to test/stress the nesting ability.
867 If any anomalies are discovered, a warning will be displayed
868 and all ring buffers will be disabled.
870 The test runs for 10 seconds. This will slow your boot time
871 by at least 10 more seconds.
873 At the end of the test, statics and more checks are done.
874 It will output the stats of each per cpu buffer. What
875 was written, the sizes, what was read, what was lost, and
876 other similar details.
880 config RING_BUFFER_VALIDATE_TIME_DELTAS
881 bool "Verify ring buffer time stamp deltas"
882 depends on RING_BUFFER
884 This will audit the time stamps on the ring buffer sub
885 buffer to make sure that all the time deltas for the
886 events on a sub buffer matches the current time stamp.
887 This audit is performed for every event that is not
888 interrupted, or interrupting another event. A check
889 is also made when traversing sub buffers to make sure
890 that all the deltas on the previous sub buffer do not
891 add up to be greater than the current time stamp.
893 NOTE: This adds significant overhead to recording of events,
894 and should only be used to test the logic of the ring buffer.
895 Do not use it on production systems.
897 Only say Y if you understand what this does, and you
898 still want it enabled. Otherwise say N
900 config MMIOTRACE_TEST
901 tristate "Test module for mmiotrace"
902 depends on MMIOTRACE && m
904 This is a dumb module for testing mmiotrace. It is very dangerous
905 as it will write garbage to IO memory starting at a given address.
906 However, it should be safe to use on e.g. unused portion of VRAM.
908 Say N, unless you absolutely know what you are doing.
910 config PREEMPTIRQ_DELAY_TEST
911 tristate "Test module to create a preempt / IRQ disable delay thread to test latency tracers"
914 Select this option to build a test module that can help test latency
915 tracers by executing a preempt or irq disable section with a user
916 configurable delay. The module busy waits for the duration of the
919 For example, the following invocation generates a burst of three
920 irq-disabled critical sections for 500us:
921 modprobe preemptirq_delay_test test_mode=irq delay=500 burst_size=3
923 What's more, if you want to attach the test on the cpu which the latency
924 tracer is running on, specify cpu_affinity=cpu_num at the end of the
929 config SYNTH_EVENT_GEN_TEST
930 tristate "Test module for in-kernel synthetic event generation"
931 depends on SYNTH_EVENTS
933 This option creates a test module to check the base
934 functionality of in-kernel synthetic event definition and
937 To test, insert the module, and then check the trace buffer
938 for the generated sample events.
942 config KPROBE_EVENT_GEN_TEST
943 tristate "Test module for in-kernel kprobe event generation"
944 depends on KPROBE_EVENTS
946 This option creates a test module to check the base
947 functionality of in-kernel kprobe event definition.
949 To test, insert the module, and then check the trace buffer
950 for the generated kprobe events.
954 config HIST_TRIGGERS_DEBUG
955 bool "Hist trigger debug support"
956 depends on HIST_TRIGGERS
958 Add "hist_debug" file for each event, which when read will
959 dump out a bunch of internal details about the hist triggers
960 defined on that event.
962 The hist_debug file serves a couple of purposes:
964 - Helps developers verify that nothing is broken.
966 - Provides educational information to support the details
967 of the hist trigger internals as described by
968 Documentation/trace/histogram-design.rst.
970 The hist_debug output only covers the data structures
971 related to the histogram definitions themselves and doesn't
972 display the internals of map buckets or variable values of
979 endif # TRACING_SUPPORT