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
18 depends on HAVE_RETHOOK
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.
24 config HAVE_FUNCTION_TRACER
27 See Documentation/trace/ftrace-design.rst
29 config HAVE_FUNCTION_GRAPH_TRACER
32 See Documentation/trace/ftrace-design.rst
34 config HAVE_FUNCTION_GRAPH_FREGS
37 config HAVE_FTRACE_GRAPH_FUNC
40 True if ftrace_graph_func() is defined.
42 config HAVE_DYNAMIC_FTRACE
45 See Documentation/trace/ftrace-design.rst
47 config HAVE_DYNAMIC_FTRACE_WITH_REGS
50 config HAVE_DYNAMIC_FTRACE_WITH_DIRECT_CALLS
53 config HAVE_DYNAMIC_FTRACE_WITH_CALL_OPS
56 config HAVE_DYNAMIC_FTRACE_WITH_ARGS
59 If this is set, then arguments and stack can be found from
60 the ftrace_regs passed into the function callback regs parameter
61 by default, even without setting the REGS flag in the ftrace_ops.
62 This allows for use of ftrace_regs_get_argument() and
63 ftrace_regs_get_stack_pointer().
65 config HAVE_FTRACE_REGS_HAVING_PT_REGS
68 If this is set, ftrace_regs has pt_regs, thus it can convert to
69 pt_regs without allocating memory.
71 config HAVE_DYNAMIC_FTRACE_NO_PATCHABLE
74 If the architecture generates __patchable_function_entries sections
75 but does not want them included in the ftrace locations.
77 config HAVE_FTRACE_MCOUNT_RECORD
80 See Documentation/trace/ftrace-design.rst
82 config HAVE_SYSCALL_TRACEPOINTS
85 See Documentation/trace/ftrace-design.rst
90 Arch supports the gcc options -pg with -mfentry
92 config HAVE_NOP_MCOUNT
95 Arch supports the gcc options -pg with -mrecord-mcount and -nop-mcount
97 config HAVE_OBJTOOL_MCOUNT
100 Arch supports objtool --mcount
102 config HAVE_OBJTOOL_NOP_MCOUNT
105 Arch supports the objtool options --mcount with --mnop.
106 An architecture can select this if it wants to enable nop'ing
109 config HAVE_C_RECORDMCOUNT
112 C version of recordmcount available?
114 config HAVE_BUILDTIME_MCOUNT_SORT
117 An architecture selects this if it sorts the mcount_loc section
120 config BUILDTIME_MCOUNT_SORT
123 depends on HAVE_BUILDTIME_MCOUNT_SORT && DYNAMIC_FTRACE
125 Sort the mcount_loc section at build time.
127 config TRACER_MAX_TRACE
139 select CONTEXT_SWITCH_TRACER
143 config CONTEXT_SWITCH_TRACER
146 config RING_BUFFER_ALLOW_SWAP
149 Allow the use of ring_buffer_swap_cpu.
150 Adds a very slight overhead to tracing when enabled.
152 config PREEMPTIRQ_TRACEPOINTS
154 depends on TRACE_PREEMPT_TOGGLE || TRACE_IRQFLAGS
158 Create preempt/irq toggle tracepoints if needed, so that other parts
159 of the kernel can use them to generate or add hooks to them.
161 # All tracer options should select GENERIC_TRACER. For those options that are
162 # enabled by all tracers (context switch and event tracer) they select TRACING.
163 # This allows those options to appear when no other tracer is selected. But the
164 # options do not appear when something else selects it. We need the two options
165 # GENERIC_TRACER and TRACING to avoid circular dependencies to accomplish the
166 # hiding of the automatic options.
171 select STACKTRACE if STACKTRACE_SUPPORT
177 select NEED_TASKS_RCU
179 config GENERIC_TRACER
184 # Minimum requirements an architecture has to meet for us to
185 # be able to offer generic tracing facilities:
187 config TRACING_SUPPORT
189 depends on TRACE_IRQFLAGS_SUPPORT
190 depends on STACKTRACE_SUPPORT
195 depends on TRACING_SUPPORT
196 default y if DEBUG_KERNEL
198 Enable the kernel tracing infrastructure.
202 config BOOTTIME_TRACING
203 bool "Boot-time Tracing support"
207 Enable developer to setup ftrace subsystem via supplemental
208 kernel cmdline at boot time for debugging (tracing) driver
209 initialization and boot process.
211 config FUNCTION_TRACER
212 bool "Kernel Function Tracer"
213 depends on HAVE_FUNCTION_TRACER
215 select GENERIC_TRACER
216 select CONTEXT_SWITCH_TRACER
218 select NEED_TASKS_RCU
219 select TASKS_RUDE_RCU
221 Enable the kernel to trace every kernel function. This is done
222 by using a compiler feature to insert a small, 5-byte No-Operation
223 instruction at the beginning of every kernel function, which NOP
224 sequence is then dynamically patched into a tracer call when
225 tracing is enabled by the administrator. If it's runtime disabled
226 (the bootup default), then the overhead of the instructions is very
227 small and not measurable even in micro-benchmarks (at least on
228 x86, but may have impact on other architectures).
230 config FUNCTION_GRAPH_TRACER
231 bool "Kernel Function Graph Tracer"
232 depends on HAVE_FUNCTION_GRAPH_TRACER
233 depends on FUNCTION_TRACER
234 depends on !X86_32 || !CC_OPTIMIZE_FOR_SIZE
237 Enable the kernel to trace a function at both its return
239 Its first purpose is to trace the duration of functions and
240 draw a call graph for each thread with some information like
241 the return value. This is done by setting the current return
242 address on the current task structure into a stack of calls.
244 config FUNCTION_GRAPH_RETVAL
245 bool "Kernel Function Graph Return Value"
246 depends on HAVE_FUNCTION_GRAPH_FREGS
247 depends on FUNCTION_GRAPH_TRACER
250 Support recording and printing the function return value when
251 using function graph tracer. It can be helpful to locate functions
252 that return errors. This feature is off by default, and you can
253 enable it via the trace option funcgraph-retval.
254 See Documentation/trace/ftrace.rst
256 config FUNCTION_GRAPH_RETADDR
257 bool "Kernel Function Graph Return Address"
258 depends on FUNCTION_GRAPH_TRACER
261 Support recording and printing the function return address when
262 using function graph tracer. It can be helpful to locate code line that
263 the function is called. This feature is off by default, and you can
264 enable it via the trace option funcgraph-retaddr.
266 config FUNCTION_TRACE_ARGS
268 depends on PROBE_EVENTS_BTF_ARGS
271 If supported with function argument access API and BTF, then
272 the function tracer and function graph tracer will support printing
273 of function arguments. This feature is off by default, and can be
274 enabled via the trace option func-args (for the function tracer) and
275 funcgraph-args (for the function graph tracer)
277 config DYNAMIC_FTRACE
278 bool "enable/disable function tracing dynamically"
279 depends on FUNCTION_TRACER
280 depends on HAVE_DYNAMIC_FTRACE
283 This option will modify all the calls to function tracing
284 dynamically (will patch them out of the binary image and
285 replace them with a No-Op instruction) on boot up. During
286 compile time, a table is made of all the locations that ftrace
287 can function trace, and this table is linked into the kernel
288 image. When this is enabled, functions can be individually
289 enabled, and the functions not enabled will not affect
290 performance of the system.
292 See the files in /sys/kernel/tracing:
293 available_filter_functions
297 This way a CONFIG_FUNCTION_TRACER kernel is slightly larger, but
298 otherwise has native performance as long as no tracing is active.
300 config DYNAMIC_FTRACE_WITH_REGS
302 depends on DYNAMIC_FTRACE
303 depends on HAVE_DYNAMIC_FTRACE_WITH_REGS
305 config DYNAMIC_FTRACE_WITH_DIRECT_CALLS
307 depends on DYNAMIC_FTRACE_WITH_REGS || DYNAMIC_FTRACE_WITH_ARGS
308 depends on HAVE_DYNAMIC_FTRACE_WITH_DIRECT_CALLS
310 config DYNAMIC_FTRACE_WITH_CALL_OPS
312 depends on HAVE_DYNAMIC_FTRACE_WITH_CALL_OPS
314 config DYNAMIC_FTRACE_WITH_ARGS
316 depends on DYNAMIC_FTRACE
317 depends on HAVE_DYNAMIC_FTRACE_WITH_ARGS
320 bool "Kernel Function Probe (fprobe)"
321 depends on HAVE_FUNCTION_GRAPH_FREGS && HAVE_FTRACE_GRAPH_FUNC
322 depends on DYNAMIC_FTRACE_WITH_ARGS
323 select FUNCTION_GRAPH_TRACER
326 This option enables kernel function probe (fprobe) based on ftrace.
327 The fprobe is similar to kprobes, but probes only for kernel function
328 entries and exits. This also can probe multiple functions by one
333 config FUNCTION_PROFILER
334 bool "Kernel function profiler"
335 depends on FUNCTION_TRACER
338 This option enables the kernel function profiler. A file is created
339 in debugfs called function_profile_enabled which defaults to zero.
340 When a 1 is echoed into this file profiling begins, and when a
341 zero is entered, profiling stops. A "functions" file is created in
342 the trace_stat directory; this file shows the list of functions that
343 have been hit and their counters.
348 bool "Trace max stack"
349 depends on HAVE_FUNCTION_TRACER
350 select FUNCTION_TRACER
354 This special tracer records the maximum stack footprint of the
355 kernel and displays it in /sys/kernel/tracing/stack_trace.
357 This tracer works by hooking into every function call that the
358 kernel executes, and keeping a maximum stack depth value and
359 stack-trace saved. If this is configured with DYNAMIC_FTRACE
360 then it will not have any overhead while the stack tracer
363 To enable the stack tracer on bootup, pass in 'stacktrace'
364 on the kernel command line.
366 The stack tracer can also be enabled or disabled via the
367 sysctl kernel.stack_tracer_enabled
371 config TRACE_PREEMPT_TOGGLE
374 Enables hooks which will be called when preemption is first disabled,
377 config IRQSOFF_TRACER
378 bool "Interrupts-off Latency Tracer"
380 depends on TRACE_IRQFLAGS_SUPPORT
381 select TRACE_IRQFLAGS
382 select GENERIC_TRACER
383 select TRACER_MAX_TRACE
384 select RING_BUFFER_ALLOW_SWAP
385 select TRACER_SNAPSHOT
386 select TRACER_SNAPSHOT_PER_CPU_SWAP
388 This option measures the time spent in irqs-off critical
389 sections, with microsecond accuracy.
391 The default measurement method is a maximum search, which is
392 disabled by default and can be runtime (re-)started
395 echo 0 > /sys/kernel/tracing/tracing_max_latency
397 (Note that kernel size and overhead increase with this option
398 enabled. This option and the preempt-off timing option can be
399 used together or separately.)
401 config PREEMPT_TRACER
402 bool "Preemption-off Latency Tracer"
404 depends on PREEMPTION
405 select GENERIC_TRACER
406 select TRACER_MAX_TRACE
407 select RING_BUFFER_ALLOW_SWAP
408 select TRACER_SNAPSHOT
409 select TRACER_SNAPSHOT_PER_CPU_SWAP
410 select TRACE_PREEMPT_TOGGLE
412 This option measures the time spent in preemption-off critical
413 sections, with microsecond accuracy.
415 The default measurement method is a maximum search, which is
416 disabled by default and can be runtime (re-)started
419 echo 0 > /sys/kernel/tracing/tracing_max_latency
421 (Note that kernel size and overhead increase with this option
422 enabled. This option and the irqs-off timing option can be
423 used together or separately.)
426 bool "Scheduling Latency Tracer"
427 select GENERIC_TRACER
428 select CONTEXT_SWITCH_TRACER
429 select TRACER_MAX_TRACE
430 select TRACER_SNAPSHOT
432 This tracer tracks the latency of the highest priority task
433 to be scheduled in, starting from the point it has woken up.
436 bool "Tracer to detect hardware latencies (like SMIs)"
437 select GENERIC_TRACER
438 select TRACER_MAX_TRACE
440 This tracer, when enabled will create one or more kernel threads,
441 depending on what the cpumask file is set to, which each thread
442 spinning in a loop looking for interruptions caused by
443 something other than the kernel. For example, if a
444 System Management Interrupt (SMI) takes a noticeable amount of
445 time, this tracer will detect it. This is useful for testing
446 if a system is reliable for Real Time tasks.
448 Some files are created in the tracing directory when this
451 hwlat_detector/width - time in usecs for how long to spin for
452 hwlat_detector/window - time in usecs between the start of each
455 A kernel thread is created that will spin with interrupts disabled
456 for "width" microseconds in every "window" cycle. It will not spin
457 for "window - width" microseconds, where the system can
460 The output will appear in the trace and trace_pipe files.
462 When the tracer is not running, it has no affect on the system,
463 but when it is running, it can cause the system to be
464 periodically non responsive. Do not run this tracer on a
467 To enable this tracer, echo in "hwlat" into the current_tracer
468 file. Every time a latency is greater than tracing_thresh, it will
469 be recorded into the ring buffer.
471 config OSNOISE_TRACER
472 bool "OS Noise tracer"
473 select GENERIC_TRACER
474 select TRACER_MAX_TRACE
476 In the context of high-performance computing (HPC), the Operating
477 System Noise (osnoise) refers to the interference experienced by an
478 application due to activities inside the operating system. In the
479 context of Linux, NMIs, IRQs, SoftIRQs, and any other system thread
480 can cause noise to the system. Moreover, hardware-related jobs can
481 also cause noise, for example, via SMIs.
483 The osnoise tracer leverages the hwlat_detector by running a similar
484 loop with preemption, SoftIRQs and IRQs enabled, thus allowing all
485 the sources of osnoise during its execution. The osnoise tracer takes
486 note of the entry and exit point of any source of interferences,
487 increasing a per-cpu interference counter. It saves an interference
488 counter for each source of interference. The interference counter for
489 NMI, IRQs, SoftIRQs, and threads is increased anytime the tool
490 observes these interferences' entry events. When a noise happens
491 without any interference from the operating system level, the
492 hardware noise counter increases, pointing to a hardware-related
493 noise. In this way, osnoise can account for any source of
494 interference. At the end of the period, the osnoise tracer prints
495 the sum of all noise, the max single noise, the percentage of CPU
496 available for the thread, and the counters for the noise sources.
498 In addition to the tracer, a set of tracepoints were added to
499 facilitate the identification of the osnoise source.
501 The output will appear in the trace and trace_pipe files.
503 To enable this tracer, echo in "osnoise" into the current_tracer
506 config TIMERLAT_TRACER
507 bool "Timerlat tracer"
508 select OSNOISE_TRACER
509 select GENERIC_TRACER
511 The timerlat tracer aims to help the preemptive kernel developers
512 to find sources of wakeup latencies of real-time threads.
514 The tracer creates a per-cpu kernel thread with real-time priority.
515 The tracer thread sets a periodic timer to wakeup itself, and goes
516 to sleep waiting for the timer to fire. At the wakeup, the thread
517 then computes a wakeup latency value as the difference between
518 the current time and the absolute time that the timer was set
521 The tracer prints two lines at every activation. The first is the
522 timer latency observed at the hardirq context before the
523 activation of the thread. The second is the timer latency observed
524 by the thread, which is the same level that cyclictest reports. The
525 ACTIVATION ID field serves to relate the irq execution to its
526 respective thread execution.
528 The tracer is build on top of osnoise tracer, and the osnoise:
529 events can be used to trace the source of interference from NMI,
530 IRQs and other threads. It also enables the capture of the
531 stacktrace at the IRQ context, which helps to identify the code
532 path that can cause thread delay.
535 bool "Memory mapped IO tracing"
536 depends on HAVE_MMIOTRACE_SUPPORT && PCI
537 select GENERIC_TRACER
539 Mmiotrace traces Memory Mapped I/O access and is meant for
540 debugging and reverse engineering. It is called from the ioremap
541 implementation and works via page faults. Tracing is disabled by
542 default and can be enabled at run-time.
544 See Documentation/trace/mmiotrace.rst.
545 If you are not helping to develop drivers, say N.
547 config ENABLE_DEFAULT_TRACERS
548 bool "Trace process context switches and events"
549 depends on !GENERIC_TRACER
552 This tracer hooks to various trace points in the kernel,
553 allowing the user to pick and choose which trace point they
554 want to trace. It also includes the sched_switch tracer plugin.
556 config FTRACE_SYSCALLS
557 bool "Trace syscalls"
558 depends on HAVE_SYSCALL_TRACEPOINTS
559 select GENERIC_TRACER
562 Basic tracer to catch the syscall entry and exit events.
564 config TRACER_SNAPSHOT
565 bool "Create a snapshot trace buffer"
566 select TRACER_MAX_TRACE
568 Allow tracing users to take snapshot of the current buffer using the
569 ftrace interface, e.g.:
571 echo 1 > /sys/kernel/tracing/snapshot
574 config TRACER_SNAPSHOT_PER_CPU_SWAP
575 bool "Allow snapshot to swap per CPU"
576 depends on TRACER_SNAPSHOT
577 select RING_BUFFER_ALLOW_SWAP
579 Allow doing a snapshot of a single CPU buffer instead of a
580 full swap (all buffers). If this is set, then the following is
583 echo 1 > /sys/kernel/tracing/per_cpu/cpu2/snapshot
585 After which, only the tracing buffer for CPU 2 was swapped with
586 the main tracing buffer, and the other CPU buffers remain the same.
588 When this is enabled, this adds a little more overhead to the
589 trace recording, as it needs to add some checks to synchronize
590 recording with swaps. But this does not affect the performance
591 of the overall system. This is enabled by default when the preempt
592 or irq latency tracers are enabled, as those need to swap as well
593 and already adds the overhead (plus a lot more).
595 config TRACE_BRANCH_PROFILING
597 select GENERIC_TRACER
600 prompt "Branch Profiling"
601 default BRANCH_PROFILE_NONE
603 The branch profiling is a software profiler. It will add hooks
604 into the C conditionals to test which path a branch takes.
606 The likely/unlikely profiler only looks at the conditions that
607 are annotated with a likely or unlikely macro.
609 The "all branch" profiler will profile every if-statement in the
610 kernel. This profiler will also enable the likely/unlikely
613 Either of the above profilers adds a bit of overhead to the system.
614 If unsure, choose "No branch profiling".
616 config BRANCH_PROFILE_NONE
617 bool "No branch profiling"
619 No branch profiling. Branch profiling adds a bit of overhead.
620 Only enable it if you want to analyse the branching behavior.
621 Otherwise keep it disabled.
623 config PROFILE_ANNOTATED_BRANCHES
624 bool "Trace likely/unlikely profiler"
625 select TRACE_BRANCH_PROFILING
627 This tracer profiles all likely and unlikely macros
628 in the kernel. It will display the results in:
630 /sys/kernel/tracing/trace_stat/branch_annotated
632 Note: this will add a significant overhead; only turn this
633 on if you need to profile the system's use of these macros.
635 config PROFILE_ALL_BRANCHES
636 bool "Profile all if conditionals" if !FORTIFY_SOURCE
637 select TRACE_BRANCH_PROFILING
639 This tracer profiles all branch conditions. Every if ()
640 taken in the kernel is recorded whether it hit or miss.
641 The results will be displayed in:
643 /sys/kernel/tracing/trace_stat/branch_all
645 This option also enables the likely/unlikely profiler.
647 This configuration, when enabled, will impose a great overhead
648 on the system. This should only be enabled when the system
649 is to be analyzed in much detail.
652 config TRACING_BRANCHES
655 Selected by tracers that will trace the likely and unlikely
656 conditions. This prevents the tracers themselves from being
657 profiled. Profiling the tracing infrastructure can only happen
658 when the likelys and unlikelys are not being traced.
661 bool "Trace likely/unlikely instances"
662 depends on TRACE_BRANCH_PROFILING
663 select TRACING_BRANCHES
665 This traces the events of likely and unlikely condition
666 calls in the kernel. The difference between this and the
667 "Trace likely/unlikely profiler" is that this is not a
668 histogram of the callers, but actually places the calling
669 events into a running trace buffer to see when and where the
670 events happened, as well as their results.
674 config BLK_DEV_IO_TRACE
675 bool "Support for tracing block IO actions"
681 select GENERIC_TRACER
684 Say Y here if you want to be able to trace the block layer actions
685 on a given queue. Tracing allows you to see any traffic happening
686 on a block device queue. For more information (and the userspace
687 support tools needed), fetch the blktrace tools from:
689 git://git.kernel.dk/blktrace.git
691 Tracing also is possible using the ftrace interface, e.g.:
693 echo 1 > /sys/block/sda/sda1/trace/enable
694 echo blk > /sys/kernel/tracing/current_tracer
695 cat /sys/kernel/tracing/trace_pipe
701 depends on HAVE_REGS_AND_STACK_ACCESS_API
702 bool "Enable fprobe-based dynamic events"
705 select DYNAMIC_EVENTS
708 This allows user to add tracing events on the function entry and
709 exit via ftrace interface. The syntax is same as the kprobe events
710 and the kprobe events on function entry and exit will be
711 transparently converted to this fprobe events.
713 config PROBE_EVENTS_BTF_ARGS
714 depends on HAVE_FUNCTION_ARG_ACCESS_API
715 depends on FPROBE_EVENTS || KPROBE_EVENTS
716 depends on DEBUG_INFO_BTF && BPF_SYSCALL
717 bool "Support BTF function arguments for probe events"
720 The user can specify the arguments of the probe event using the names
721 of the arguments of the probed function, when the probe location is a
722 kernel function entry or a tracepoint.
723 This is available only if BTF (BPF Type Format) support is enabled.
727 depends on HAVE_REGS_AND_STACK_ACCESS_API
728 bool "Enable kprobes-based dynamic events"
731 select DYNAMIC_EVENTS
734 This allows the user to add tracing events (similar to tracepoints)
735 on the fly via the ftrace interface. See
736 Documentation/trace/kprobetrace.rst for more details.
738 Those events can be inserted wherever kprobes can probe, and record
739 various register and memory values.
741 This option is also required by perf-probe subcommand of perf tools.
742 If you want to use perf tools, this option is strongly recommended.
744 config KPROBE_EVENTS_ON_NOTRACE
745 bool "Do NOT protect notrace function from kprobe events"
746 depends on KPROBE_EVENTS
747 depends on DYNAMIC_FTRACE
750 This is only for the developers who want to debug ftrace itself
753 If kprobes can use ftrace instead of breakpoint, ftrace related
754 functions are protected from kprobe-events to prevent an infinite
755 recursion or any unexpected execution path which leads to a kernel
758 This option disables such protection and allows you to put kprobe
759 events on ftrace functions for debugging ftrace by itself.
760 Note that this might let you shoot yourself in the foot.
765 bool "Enable uprobes-based dynamic events"
766 depends on ARCH_SUPPORTS_UPROBES
768 depends on PERF_EVENTS
771 select DYNAMIC_EVENTS
775 This allows the user to add tracing events on top of userspace
776 dynamic events (similar to tracepoints) on the fly via the trace
777 events interface. Those events can be inserted wherever uprobes
778 can probe, and record various registers.
779 This option is required if you plan to use perf-probe subcommand
780 of perf tools on user space applications.
783 depends on BPF_SYSCALL
784 depends on (KPROBE_EVENTS || UPROBE_EVENTS) && PERF_EVENTS
788 This allows the user to attach BPF programs to kprobe, uprobe, and
791 config DYNAMIC_EVENTS
797 config BPF_KPROBE_OVERRIDE
798 bool "Enable BPF programs to override a kprobed function"
799 depends on BPF_EVENTS
800 depends on FUNCTION_ERROR_INJECTION
803 Allows BPF to override the execution of a probed function and
804 set a different return value. This is used for error injection.
806 config FTRACE_MCOUNT_RECORD
808 depends on DYNAMIC_FTRACE
809 depends on HAVE_FTRACE_MCOUNT_RECORD
811 config FTRACE_MCOUNT_USE_PATCHABLE_FUNCTION_ENTRY
813 depends on FTRACE_MCOUNT_RECORD
815 config FTRACE_MCOUNT_USE_CC
817 depends on $(cc-option,-mrecord-mcount)
818 depends on !FTRACE_MCOUNT_USE_PATCHABLE_FUNCTION_ENTRY
819 depends on FTRACE_MCOUNT_RECORD
821 config FTRACE_MCOUNT_USE_OBJTOOL
823 depends on HAVE_OBJTOOL_MCOUNT
824 depends on !FTRACE_MCOUNT_USE_PATCHABLE_FUNCTION_ENTRY
825 depends on !FTRACE_MCOUNT_USE_CC
826 depends on FTRACE_MCOUNT_RECORD
829 config FTRACE_MCOUNT_USE_RECORDMCOUNT
831 depends on !FTRACE_MCOUNT_USE_PATCHABLE_FUNCTION_ENTRY
832 depends on !FTRACE_MCOUNT_USE_CC
833 depends on !FTRACE_MCOUNT_USE_OBJTOOL
834 depends on FTRACE_MCOUNT_RECORD
838 depends on ARCH_HAVE_NMI_SAFE_CMPXCHG
840 tracing_map is a special-purpose lock-free map for tracing,
841 separated out as a stand-alone facility in order to allow it
842 to be shared between multiple tracers. It isn't meant to be
843 generally used outside of that context, and is normally
844 selected by tracers that use it.
847 bool "Synthetic trace events"
849 select DYNAMIC_EVENTS
852 Synthetic events are user-defined trace events that can be
853 used to combine data from other trace events or in fact any
854 data source. Synthetic events can be generated indirectly
855 via the trace() action of histogram triggers or directly
856 by way of an in-kernel API.
858 See Documentation/trace/events.rst or
859 Documentation/trace/histogram.rst for details and examples.
864 bool "User trace events"
866 select DYNAMIC_EVENTS
868 User trace events are user-defined trace events that
869 can be used like an existing kernel trace event. User trace
870 events are generated by writing to a tracefs file. User
871 processes can determine if their tracing events should be
872 generated by registering a value and bit with the kernel
873 that reflects when it is enabled or not.
875 See Documentation/trace/user_events.rst.
879 bool "Histogram triggers"
880 depends on ARCH_HAVE_NMI_SAFE_CMPXCHG
883 select DYNAMIC_EVENTS
887 Hist triggers allow one or more arbitrary trace event fields
888 to be aggregated into hash tables and dumped to stdout by
889 reading a debugfs/tracefs file. They're useful for
890 gathering quick and dirty (though precise) summaries of
891 event activity as an initial guide for further investigation
892 using more advanced tools.
894 Inter-event tracing of quantities such as latencies is also
895 supported using hist triggers under this option.
897 See Documentation/trace/histogram.rst.
900 config TRACE_EVENT_INJECT
901 bool "Trace event injection"
904 Allow user-space to inject a specific trace event into the ring
905 buffer. This is mainly used for testing purpose.
909 config TRACEPOINT_BENCHMARK
910 bool "Add tracepoint that benchmarks tracepoints"
912 This option creates the tracepoint "benchmark:benchmark_event".
913 When the tracepoint is enabled, it kicks off a kernel thread that
914 goes into an infinite loop (calling cond_resched() to let other tasks
915 run), and calls the tracepoint. Each iteration will record the time
916 it took to write to the tracepoint and the next iteration that
917 data will be passed to the tracepoint itself. That is, the tracepoint
918 will report the time it took to do the previous tracepoint.
919 The string written to the tracepoint is a static string of 128 bytes
920 to keep the time the same. The initial string is simply a write of
921 "START". The second string records the cold cache time of the first
922 write which is not added to the rest of the calculations.
924 As it is a tight loop, it benchmarks as hot cache. That's fine because
925 we care most about hot paths that are probably in cache already.
927 An example of the output:
930 first=3672 [COLD CACHED]
931 last=632 first=3672 max=632 min=632 avg=316 std=446 std^2=199712
932 last=278 first=3672 max=632 min=278 avg=303 std=316 std^2=100337
933 last=277 first=3672 max=632 min=277 avg=296 std=258 std^2=67064
934 last=273 first=3672 max=632 min=273 avg=292 std=224 std^2=50411
935 last=273 first=3672 max=632 min=273 avg=288 std=200 std^2=40389
936 last=281 first=3672 max=632 min=273 avg=287 std=183 std^2=33666
939 config RING_BUFFER_BENCHMARK
940 tristate "Ring buffer benchmark stress tester"
941 depends on RING_BUFFER
943 This option creates a test to stress the ring buffer and benchmark it.
944 It creates its own ring buffer such that it will not interfere with
945 any other users of the ring buffer (such as ftrace). It then creates
946 a producer and consumer that will run for 10 seconds and sleep for
947 10 seconds. Each interval it will print out the number of events
948 it recorded and give a rough estimate of how long each iteration took.
950 It does not disable interrupts or raise its priority, so it may be
951 affected by processes that are running.
955 config TRACE_EVAL_MAP_FILE
956 bool "Show eval mappings for trace events"
959 The "print fmt" of the trace events will show the enum/sizeof names
960 instead of their values. This can cause problems for user space tools
961 that use this string to parse the raw data as user space does not know
962 how to convert the string to its value.
964 To fix this, there's a special macro in the kernel that can be used
965 to convert an enum/sizeof into its value. If this macro is used, then
966 the print fmt strings will be converted to their values.
968 If something does not get converted properly, this option can be
969 used to show what enums/sizeof the kernel tried to convert.
971 This option is for debugging the conversions. A file is created
972 in the tracing directory called "eval_map" that will show the
973 names matched with their values and what trace event system they
976 Normally, the mapping of the strings to values will be freed after
977 boot up or module load. With this option, they will not be freed, as
978 they are needed for the "eval_map" file. Enabling this option will
979 increase the memory footprint of the running kernel.
983 config FTRACE_RECORD_RECURSION
984 bool "Record functions that recurse in function tracing"
985 depends on FUNCTION_TRACER
987 All callbacks that attach to the function tracing have some sort
988 of protection against recursion. Even though the protection exists,
989 it adds overhead. This option will create a file in the tracefs
990 file system called "recursed_functions" that will list the functions
991 that triggered a recursion.
993 This will add more overhead to cases that have recursion.
997 config FTRACE_RECORD_RECURSION_SIZE
998 int "Max number of recursed functions to record"
1000 depends on FTRACE_RECORD_RECURSION
1002 This defines the limit of number of functions that can be
1003 listed in the "recursed_functions" file, that lists all
1004 the functions that caused a recursion to happen.
1005 This file can be reset, but the limit can not change in
1008 config FTRACE_VALIDATE_RCU_IS_WATCHING
1009 bool "Validate RCU is on during ftrace execution"
1010 depends on FUNCTION_TRACER
1011 depends on ARCH_WANTS_NO_INSTR
1013 All callbacks that attach to the function tracing have some sort of
1014 protection against recursion. This option is only to verify that
1015 ftrace (and other users of ftrace_test_recursion_trylock()) are not
1016 called outside of RCU, as if they are, it can cause a race. But it
1017 also has a noticeable overhead when enabled.
1021 config RING_BUFFER_RECORD_RECURSION
1022 bool "Record functions that recurse in the ring buffer"
1023 depends on FTRACE_RECORD_RECURSION
1024 # default y, because it is coupled with FTRACE_RECORD_RECURSION
1027 The ring buffer has its own internal recursion. Although when
1028 recursion happens it won't cause harm because of the protection,
1029 but it does cause unwanted overhead. Enabling this option will
1030 place where recursion was detected into the ftrace "recursed_functions"
1033 This will add more overhead to cases that have recursion.
1035 config GCOV_PROFILE_FTRACE
1036 bool "Enable GCOV profiling on ftrace subsystem"
1037 depends on GCOV_KERNEL
1039 Enable GCOV profiling on ftrace subsystem for checking
1040 which functions/lines are tested.
1044 Note that on a kernel compiled with this config, ftrace will
1045 run significantly slower.
1047 config FTRACE_SELFTEST
1050 config FTRACE_STARTUP_TEST
1051 bool "Perform a startup test on ftrace"
1052 depends on GENERIC_TRACER
1053 select FTRACE_SELFTEST
1055 This option performs a series of startup tests on ftrace. On bootup
1056 a series of tests are made to verify that the tracer is
1057 functioning properly. It will do tests on all the configured
1060 config EVENT_TRACE_STARTUP_TEST
1061 bool "Run selftest on trace events"
1062 depends on FTRACE_STARTUP_TEST
1065 This option performs a test on all trace events in the system.
1066 It basically just enables each event and runs some code that
1067 will trigger events (not necessarily the event it enables)
1068 This may take some time run as there are a lot of events.
1070 config EVENT_TRACE_TEST_SYSCALLS
1071 bool "Run selftest on syscall events"
1072 depends on EVENT_TRACE_STARTUP_TEST
1074 This option will also enable testing every syscall event.
1075 It only enables the event and disables it and runs various loads
1076 with the event enabled. This adds a bit more time for kernel boot
1077 up since it runs this on every system call defined.
1079 TBD - enable a way to actually call the syscalls as we test their
1082 config FTRACE_SORT_STARTUP_TEST
1083 bool "Verify compile time sorting of ftrace functions"
1084 depends on DYNAMIC_FTRACE
1085 depends on BUILDTIME_MCOUNT_SORT
1087 Sorting of the mcount_loc sections that is used to find the
1088 where the ftrace knows where to patch functions for tracing
1089 and other callbacks is done at compile time. But if the sort
1090 is not done correctly, it will cause non-deterministic failures.
1091 When this is set, the sorted sections will be verified that they
1092 are in deed sorted and will warn if they are not.
1096 config RING_BUFFER_STARTUP_TEST
1097 bool "Ring buffer startup self test"
1098 depends on RING_BUFFER
1100 Run a simple self test on the ring buffer on boot up. Late in the
1101 kernel boot sequence, the test will start that kicks off
1102 a thread per cpu. Each thread will write various size events
1103 into the ring buffer. Another thread is created to send IPIs
1104 to each of the threads, where the IPI handler will also write
1105 to the ring buffer, to test/stress the nesting ability.
1106 If any anomalies are discovered, a warning will be displayed
1107 and all ring buffers will be disabled.
1109 The test runs for 10 seconds. This will slow your boot time
1110 by at least 10 more seconds.
1112 At the end of the test, statistics and more checks are done.
1113 It will output the stats of each per cpu buffer: What
1114 was written, the sizes, what was read, what was lost, and
1115 other similar details.
1119 config RING_BUFFER_VALIDATE_TIME_DELTAS
1120 bool "Verify ring buffer time stamp deltas"
1121 depends on RING_BUFFER
1123 This will audit the time stamps on the ring buffer sub
1124 buffer to make sure that all the time deltas for the
1125 events on a sub buffer matches the current time stamp.
1126 This audit is performed for every event that is not
1127 interrupted, or interrupting another event. A check
1128 is also made when traversing sub buffers to make sure
1129 that all the deltas on the previous sub buffer do not
1130 add up to be greater than the current time stamp.
1132 NOTE: This adds significant overhead to recording of events,
1133 and should only be used to test the logic of the ring buffer.
1134 Do not use it on production systems.
1136 Only say Y if you understand what this does, and you
1137 still want it enabled. Otherwise say N
1139 config MMIOTRACE_TEST
1140 tristate "Test module for mmiotrace"
1141 depends on MMIOTRACE && m
1143 This is a dumb module for testing mmiotrace. It is very dangerous
1144 as it will write garbage to IO memory starting at a given address.
1145 However, it should be safe to use on e.g. unused portion of VRAM.
1147 Say N, unless you absolutely know what you are doing.
1149 config PREEMPTIRQ_DELAY_TEST
1150 tristate "Test module to create a preempt / IRQ disable delay thread to test latency tracers"
1153 Select this option to build a test module that can help test latency
1154 tracers by executing a preempt or irq disable section with a user
1155 configurable delay. The module busy waits for the duration of the
1158 For example, the following invocation generates a burst of three
1159 irq-disabled critical sections for 500us:
1160 modprobe preemptirq_delay_test test_mode=irq delay=500 burst_size=3
1162 What's more, if you want to attach the test on the cpu which the latency
1163 tracer is running on, specify cpu_affinity=cpu_num at the end of the
1168 config SYNTH_EVENT_GEN_TEST
1169 tristate "Test module for in-kernel synthetic event generation"
1170 depends on SYNTH_EVENTS && m
1172 This option creates a test module to check the base
1173 functionality of in-kernel synthetic event definition and
1176 To test, insert the module, and then check the trace buffer
1177 for the generated sample events.
1181 config KPROBE_EVENT_GEN_TEST
1182 tristate "Test module for in-kernel kprobe event generation"
1183 depends on KPROBE_EVENTS && m
1185 This option creates a test module to check the base
1186 functionality of in-kernel kprobe event definition.
1188 To test, insert the module, and then check the trace buffer
1189 for the generated kprobe events.
1193 config HIST_TRIGGERS_DEBUG
1194 bool "Hist trigger debug support"
1195 depends on HIST_TRIGGERS
1197 Add "hist_debug" file for each event, which when read will
1198 dump out a bunch of internal details about the hist triggers
1199 defined on that event.
1201 The hist_debug file serves a couple of purposes:
1203 - Helps developers verify that nothing is broken.
1205 - Provides educational information to support the details
1206 of the hist trigger internals as described by
1207 Documentation/trace/histogram-design.rst.
1209 The hist_debug output only covers the data structures
1210 related to the histogram definitions themselves and doesn't
1211 display the internals of map buckets or variable values of
1216 source "kernel/trace/rv/Kconfig"
projects / linux-2.6-block.git / blob