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