Merge branch 'x86/mm' into x86/asm, to unify the two branches for simplicity
[cascardo/linux.git] / kernel / trace / Kconfig
1 #
2 # Architectures that offer an FUNCTION_TRACER implementation should
3 #  select HAVE_FUNCTION_TRACER:
4 #
5
6 config USER_STACKTRACE_SUPPORT
7         bool
8
9 config NOP_TRACER
10         bool
11
12 config HAVE_FTRACE_NMI_ENTER
13         bool
14         help
15           See Documentation/trace/ftrace-design.txt
16
17 config HAVE_FUNCTION_TRACER
18         bool
19         help
20           See Documentation/trace/ftrace-design.txt
21
22 config HAVE_FUNCTION_GRAPH_TRACER
23         bool
24         help
25           See Documentation/trace/ftrace-design.txt
26
27 config HAVE_DYNAMIC_FTRACE
28         bool
29         help
30           See Documentation/trace/ftrace-design.txt
31
32 config HAVE_DYNAMIC_FTRACE_WITH_REGS
33         bool
34
35 config HAVE_FTRACE_MCOUNT_RECORD
36         bool
37         help
38           See Documentation/trace/ftrace-design.txt
39
40 config HAVE_SYSCALL_TRACEPOINTS
41         bool
42         help
43           See Documentation/trace/ftrace-design.txt
44
45 config HAVE_FENTRY
46         bool
47         help
48           Arch supports the gcc options -pg with -mfentry
49
50 config HAVE_C_RECORDMCOUNT
51         bool
52         help
53           C version of recordmcount available?
54
55 config TRACER_MAX_TRACE
56         bool
57
58 config TRACE_CLOCK
59         bool
60
61 config RING_BUFFER
62         bool
63         select TRACE_CLOCK
64         select IRQ_WORK
65
66 config FTRACE_NMI_ENTER
67        bool
68        depends on HAVE_FTRACE_NMI_ENTER
69        default y
70
71 config EVENT_TRACING
72         select CONTEXT_SWITCH_TRACER
73         bool
74
75 config CONTEXT_SWITCH_TRACER
76         bool
77
78 config RING_BUFFER_ALLOW_SWAP
79         bool
80         help
81          Allow the use of ring_buffer_swap_cpu.
82          Adds a very slight overhead to tracing when enabled.
83
84 # All tracer options should select GENERIC_TRACER. For those options that are
85 # enabled by all tracers (context switch and event tracer) they select TRACING.
86 # This allows those options to appear when no other tracer is selected. But the
87 # options do not appear when something else selects it. We need the two options
88 # GENERIC_TRACER and TRACING to avoid circular dependencies to accomplish the
89 # hiding of the automatic options.
90
91 config TRACING
92         bool
93         select DEBUG_FS
94         select RING_BUFFER
95         select STACKTRACE if STACKTRACE_SUPPORT
96         select TRACEPOINTS
97         select NOP_TRACER
98         select BINARY_PRINTF
99         select EVENT_TRACING
100         select TRACE_CLOCK
101
102 config GENERIC_TRACER
103         bool
104         select TRACING
105
106 #
107 # Minimum requirements an architecture has to meet for us to
108 # be able to offer generic tracing facilities:
109 #
110 config TRACING_SUPPORT
111         bool
112         # PPC32 has no irqflags tracing support, but it can use most of the
113         # tracers anyway, they were tested to build and work. Note that new
114         # exceptions to this list aren't welcomed, better implement the
115         # irqflags tracing for your architecture.
116         depends on TRACE_IRQFLAGS_SUPPORT || PPC32
117         depends on STACKTRACE_SUPPORT
118         default y
119
120 if TRACING_SUPPORT
121
122 menuconfig FTRACE
123         bool "Tracers"
124         default y if DEBUG_KERNEL
125         help
126           Enable the kernel tracing infrastructure.
127
128 if FTRACE
129
130 config FUNCTION_TRACER
131         bool "Kernel Function Tracer"
132         depends on HAVE_FUNCTION_TRACER
133         select KALLSYMS
134         select GENERIC_TRACER
135         select CONTEXT_SWITCH_TRACER
136         help
137           Enable the kernel to trace every kernel function. This is done
138           by using a compiler feature to insert a small, 5-byte No-Operation
139           instruction at the beginning of every kernel function, which NOP
140           sequence is then dynamically patched into a tracer call when
141           tracing is enabled by the administrator. If it's runtime disabled
142           (the bootup default), then the overhead of the instructions is very
143           small and not measurable even in micro-benchmarks.
144
145 config FUNCTION_GRAPH_TRACER
146         bool "Kernel Function Graph Tracer"
147         depends on HAVE_FUNCTION_GRAPH_TRACER
148         depends on FUNCTION_TRACER
149         depends on !X86_32 || !CC_OPTIMIZE_FOR_SIZE
150         default y
151         help
152           Enable the kernel to trace a function at both its return
153           and its entry.
154           Its first purpose is to trace the duration of functions and
155           draw a call graph for each thread with some information like
156           the return value. This is done by setting the current return
157           address on the current task structure into a stack of calls.
158
159
160 config IRQSOFF_TRACER
161         bool "Interrupts-off Latency Tracer"
162         default n
163         depends on TRACE_IRQFLAGS_SUPPORT
164         depends on !ARCH_USES_GETTIMEOFFSET
165         select TRACE_IRQFLAGS
166         select GENERIC_TRACER
167         select TRACER_MAX_TRACE
168         select RING_BUFFER_ALLOW_SWAP
169         select TRACER_SNAPSHOT
170         select TRACER_SNAPSHOT_PER_CPU_SWAP
171         help
172           This option measures the time spent in irqs-off critical
173           sections, with microsecond accuracy.
174
175           The default measurement method is a maximum search, which is
176           disabled by default and can be runtime (re-)started
177           via:
178
179               echo 0 > /sys/kernel/debug/tracing/tracing_max_latency
180
181           (Note that kernel size and overhead increase with this option
182           enabled. This option and the preempt-off timing option can be
183           used together or separately.)
184
185 config PREEMPT_TRACER
186         bool "Preemption-off Latency Tracer"
187         default n
188         depends on !ARCH_USES_GETTIMEOFFSET
189         depends on PREEMPT
190         select GENERIC_TRACER
191         select TRACER_MAX_TRACE
192         select RING_BUFFER_ALLOW_SWAP
193         select TRACER_SNAPSHOT
194         select TRACER_SNAPSHOT_PER_CPU_SWAP
195         help
196           This option measures the time spent in preemption-off critical
197           sections, with microsecond accuracy.
198
199           The default measurement method is a maximum search, which is
200           disabled by default and can be runtime (re-)started
201           via:
202
203               echo 0 > /sys/kernel/debug/tracing/tracing_max_latency
204
205           (Note that kernel size and overhead increase with this option
206           enabled. This option and the irqs-off timing option can be
207           used together or separately.)
208
209 config SCHED_TRACER
210         bool "Scheduling Latency Tracer"
211         select GENERIC_TRACER
212         select CONTEXT_SWITCH_TRACER
213         select TRACER_MAX_TRACE
214         select TRACER_SNAPSHOT
215         help
216           This tracer tracks the latency of the highest priority task
217           to be scheduled in, starting from the point it has woken up.
218
219 config ENABLE_DEFAULT_TRACERS
220         bool "Trace process context switches and events"
221         depends on !GENERIC_TRACER
222         select TRACING
223         help
224           This tracer hooks to various trace points in the kernel,
225           allowing the user to pick and choose which trace point they
226           want to trace. It also includes the sched_switch tracer plugin.
227
228 config FTRACE_SYSCALLS
229         bool "Trace syscalls"
230         depends on HAVE_SYSCALL_TRACEPOINTS
231         select GENERIC_TRACER
232         select KALLSYMS
233         help
234           Basic tracer to catch the syscall entry and exit events.
235
236 config TRACER_SNAPSHOT
237         bool "Create a snapshot trace buffer"
238         select TRACER_MAX_TRACE
239         help
240           Allow tracing users to take snapshot of the current buffer using the
241           ftrace interface, e.g.:
242
243               echo 1 > /sys/kernel/debug/tracing/snapshot
244               cat snapshot
245
246 config TRACER_SNAPSHOT_PER_CPU_SWAP
247         bool "Allow snapshot to swap per CPU"
248         depends on TRACER_SNAPSHOT
249         select RING_BUFFER_ALLOW_SWAP
250         help
251           Allow doing a snapshot of a single CPU buffer instead of a
252           full swap (all buffers). If this is set, then the following is
253           allowed:
254
255               echo 1 > /sys/kernel/debug/tracing/per_cpu/cpu2/snapshot
256
257           After which, only the tracing buffer for CPU 2 was swapped with
258           the main tracing buffer, and the other CPU buffers remain the same.
259
260           When this is enabled, this adds a little more overhead to the
261           trace recording, as it needs to add some checks to synchronize
262           recording with swaps. But this does not affect the performance
263           of the overall system. This is enabled by default when the preempt
264           or irq latency tracers are enabled, as those need to swap as well
265           and already adds the overhead (plus a lot more).
266
267 config TRACE_BRANCH_PROFILING
268         bool
269         select GENERIC_TRACER
270
271 choice
272         prompt "Branch Profiling"
273         default BRANCH_PROFILE_NONE
274         help
275          The branch profiling is a software profiler. It will add hooks
276          into the C conditionals to test which path a branch takes.
277
278          The likely/unlikely profiler only looks at the conditions that
279          are annotated with a likely or unlikely macro.
280
281          The "all branch" profiler will profile every if-statement in the
282          kernel. This profiler will also enable the likely/unlikely
283          profiler.
284
285          Either of the above profilers adds a bit of overhead to the system.
286          If unsure, choose "No branch profiling".
287
288 config BRANCH_PROFILE_NONE
289         bool "No branch profiling"
290         help
291           No branch profiling. Branch profiling adds a bit of overhead.
292           Only enable it if you want to analyse the branching behavior.
293           Otherwise keep it disabled.
294
295 config PROFILE_ANNOTATED_BRANCHES
296         bool "Trace likely/unlikely profiler"
297         select TRACE_BRANCH_PROFILING
298         help
299           This tracer profiles all likely and unlikely macros
300           in the kernel. It will display the results in:
301
302           /sys/kernel/debug/tracing/trace_stat/branch_annotated
303
304           Note: this will add a significant overhead; only turn this
305           on if you need to profile the system's use of these macros.
306
307 config PROFILE_ALL_BRANCHES
308         bool "Profile all if conditionals"
309         select TRACE_BRANCH_PROFILING
310         help
311           This tracer profiles all branch conditions. Every if ()
312           taken in the kernel is recorded whether it hit or miss.
313           The results will be displayed in:
314
315           /sys/kernel/debug/tracing/trace_stat/branch_all
316
317           This option also enables the likely/unlikely profiler.
318
319           This configuration, when enabled, will impose a great overhead
320           on the system. This should only be enabled when the system
321           is to be analyzed in much detail.
322 endchoice
323
324 config TRACING_BRANCHES
325         bool
326         help
327           Selected by tracers that will trace the likely and unlikely
328           conditions. This prevents the tracers themselves from being
329           profiled. Profiling the tracing infrastructure can only happen
330           when the likelys and unlikelys are not being traced.
331
332 config BRANCH_TRACER
333         bool "Trace likely/unlikely instances"
334         depends on TRACE_BRANCH_PROFILING
335         select TRACING_BRANCHES
336         help
337           This traces the events of likely and unlikely condition
338           calls in the kernel.  The difference between this and the
339           "Trace likely/unlikely profiler" is that this is not a
340           histogram of the callers, but actually places the calling
341           events into a running trace buffer to see when and where the
342           events happened, as well as their results.
343
344           Say N if unsure.
345
346 config STACK_TRACER
347         bool "Trace max stack"
348         depends on HAVE_FUNCTION_TRACER
349         select FUNCTION_TRACER
350         select STACKTRACE
351         select KALLSYMS
352         help
353           This special tracer records the maximum stack footprint of the
354           kernel and displays it in /sys/kernel/debug/tracing/stack_trace.
355
356           This tracer works by hooking into every function call that the
357           kernel executes, and keeping a maximum stack depth value and
358           stack-trace saved.  If this is configured with DYNAMIC_FTRACE
359           then it will not have any overhead while the stack tracer
360           is disabled.
361
362           To enable the stack tracer on bootup, pass in 'stacktrace'
363           on the kernel command line.
364
365           The stack tracer can also be enabled or disabled via the
366           sysctl kernel.stack_tracer_enabled
367
368           Say N if unsure.
369
370 config BLK_DEV_IO_TRACE
371         bool "Support for tracing block IO actions"
372         depends on SYSFS
373         depends on BLOCK
374         select RELAY
375         select DEBUG_FS
376         select TRACEPOINTS
377         select GENERIC_TRACER
378         select STACKTRACE
379         help
380           Say Y here if you want to be able to trace the block layer actions
381           on a given queue. Tracing allows you to see any traffic happening
382           on a block device queue. For more information (and the userspace
383           support tools needed), fetch the blktrace tools from:
384
385           git://git.kernel.dk/blktrace.git
386
387           Tracing also is possible using the ftrace interface, e.g.:
388
389             echo 1 > /sys/block/sda/sda1/trace/enable
390             echo blk > /sys/kernel/debug/tracing/current_tracer
391             cat /sys/kernel/debug/tracing/trace_pipe
392
393           If unsure, say N.
394
395 config KPROBE_EVENT
396         depends on KPROBES
397         depends on HAVE_REGS_AND_STACK_ACCESS_API
398         bool "Enable kprobes-based dynamic events"
399         select TRACING
400         select PROBE_EVENTS
401         default y
402         help
403           This allows the user to add tracing events (similar to tracepoints)
404           on the fly via the ftrace interface. See
405           Documentation/trace/kprobetrace.txt for more details.
406
407           Those events can be inserted wherever kprobes can probe, and record
408           various register and memory values.
409
410           This option is also required by perf-probe subcommand of perf tools.
411           If you want to use perf tools, this option is strongly recommended.
412
413 config UPROBE_EVENT
414         bool "Enable uprobes-based dynamic events"
415         depends on ARCH_SUPPORTS_UPROBES
416         depends on MMU
417         depends on PERF_EVENTS
418         select UPROBES
419         select PROBE_EVENTS
420         select TRACING
421         default n
422         help
423           This allows the user to add tracing events on top of userspace
424           dynamic events (similar to tracepoints) on the fly via the trace
425           events interface. Those events can be inserted wherever uprobes
426           can probe, and record various registers.
427           This option is required if you plan to use perf-probe subcommand
428           of perf tools on user space applications.
429
430 config BPF_EVENTS
431         depends on BPF_SYSCALL
432         depends on (KPROBE_EVENT || UPROBE_EVENT) && PERF_EVENTS
433         bool
434         default y
435         help
436           This allows the user to attach BPF programs to kprobe events.
437
438 config PROBE_EVENTS
439         def_bool n
440
441 config DYNAMIC_FTRACE
442         bool "enable/disable function tracing dynamically"
443         depends on FUNCTION_TRACER
444         depends on HAVE_DYNAMIC_FTRACE
445         default y
446         help
447           This option will modify all the calls to function tracing
448           dynamically (will patch them out of the binary image and
449           replace them with a No-Op instruction) on boot up. During
450           compile time, a table is made of all the locations that ftrace
451           can function trace, and this table is linked into the kernel
452           image. When this is enabled, functions can be individually
453           enabled, and the functions not enabled will not affect
454           performance of the system.
455
456           See the files in /sys/kernel/debug/tracing:
457             available_filter_functions
458             set_ftrace_filter
459             set_ftrace_notrace
460
461           This way a CONFIG_FUNCTION_TRACER kernel is slightly larger, but
462           otherwise has native performance as long as no tracing is active.
463
464 config DYNAMIC_FTRACE_WITH_REGS
465         def_bool y
466         depends on DYNAMIC_FTRACE
467         depends on HAVE_DYNAMIC_FTRACE_WITH_REGS
468
469 config FUNCTION_PROFILER
470         bool "Kernel function profiler"
471         depends on FUNCTION_TRACER
472         default n
473         help
474           This option enables the kernel function profiler. A file is created
475           in debugfs called function_profile_enabled which defaults to zero.
476           When a 1 is echoed into this file profiling begins, and when a
477           zero is entered, profiling stops. A "functions" file is created in
478           the trace_stats directory; this file shows the list of functions that
479           have been hit and their counters.
480
481           If in doubt, say N.
482
483 config FTRACE_MCOUNT_RECORD
484         def_bool y
485         depends on DYNAMIC_FTRACE
486         depends on HAVE_FTRACE_MCOUNT_RECORD
487
488 config FTRACE_SELFTEST
489         bool
490
491 config FTRACE_STARTUP_TEST
492         bool "Perform a startup test on ftrace"
493         depends on GENERIC_TRACER
494         select FTRACE_SELFTEST
495         help
496           This option performs a series of startup tests on ftrace. On bootup
497           a series of tests are made to verify that the tracer is
498           functioning properly. It will do tests on all the configured
499           tracers of ftrace.
500
501 config EVENT_TRACE_TEST_SYSCALLS
502         bool "Run selftest on syscall events"
503         depends on FTRACE_STARTUP_TEST
504         help
505          This option will also enable testing every syscall event.
506          It only enables the event and disables it and runs various loads
507          with the event enabled. This adds a bit more time for kernel boot
508          up since it runs this on every system call defined.
509
510          TBD - enable a way to actually call the syscalls as we test their
511                events
512
513 config MMIOTRACE
514         bool "Memory mapped IO tracing"
515         depends on HAVE_MMIOTRACE_SUPPORT && PCI
516         select GENERIC_TRACER
517         help
518           Mmiotrace traces Memory Mapped I/O access and is meant for
519           debugging and reverse engineering. It is called from the ioremap
520           implementation and works via page faults. Tracing is disabled by
521           default and can be enabled at run-time.
522
523           See Documentation/trace/mmiotrace.txt.
524           If you are not helping to develop drivers, say N.
525
526 config TRACING_MAP
527         bool
528         depends on ARCH_HAVE_NMI_SAFE_CMPXCHG
529         help
530           tracing_map is a special-purpose lock-free map for tracing,
531           separated out as a stand-alone facility in order to allow it
532           to be shared between multiple tracers.  It isn't meant to be
533           generally used outside of that context, and is normally
534           selected by tracers that use it.
535
536 config HIST_TRIGGERS
537         bool "Histogram triggers"
538         depends on ARCH_HAVE_NMI_SAFE_CMPXCHG
539         select TRACING_MAP
540         select TRACING
541         default n
542         help
543           Hist triggers allow one or more arbitrary trace event fields
544           to be aggregated into hash tables and dumped to stdout by
545           reading a debugfs/tracefs file.  They're useful for
546           gathering quick and dirty (though precise) summaries of
547           event activity as an initial guide for further investigation
548           using more advanced tools.
549
550           See Documentation/trace/events.txt.
551           If in doubt, say N.
552
553 config MMIOTRACE_TEST
554         tristate "Test module for mmiotrace"
555         depends on MMIOTRACE && m
556         help
557           This is a dumb module for testing mmiotrace. It is very dangerous
558           as it will write garbage to IO memory starting at a given address.
559           However, it should be safe to use on e.g. unused portion of VRAM.
560
561           Say N, unless you absolutely know what you are doing.
562
563 config TRACEPOINT_BENCHMARK
564         bool "Add tracepoint that benchmarks tracepoints"
565         help
566          This option creates the tracepoint "benchmark:benchmark_event".
567          When the tracepoint is enabled, it kicks off a kernel thread that
568          goes into an infinite loop (calling cond_sched() to let other tasks
569          run), and calls the tracepoint. Each iteration will record the time
570          it took to write to the tracepoint and the next iteration that
571          data will be passed to the tracepoint itself. That is, the tracepoint
572          will report the time it took to do the previous tracepoint.
573          The string written to the tracepoint is a static string of 128 bytes
574          to keep the time the same. The initial string is simply a write of
575          "START". The second string records the cold cache time of the first
576          write which is not added to the rest of the calculations.
577
578          As it is a tight loop, it benchmarks as hot cache. That's fine because
579          we care most about hot paths that are probably in cache already.
580
581          An example of the output:
582
583               START
584               first=3672 [COLD CACHED]
585               last=632 first=3672 max=632 min=632 avg=316 std=446 std^2=199712
586               last=278 first=3672 max=632 min=278 avg=303 std=316 std^2=100337
587               last=277 first=3672 max=632 min=277 avg=296 std=258 std^2=67064
588               last=273 first=3672 max=632 min=273 avg=292 std=224 std^2=50411
589               last=273 first=3672 max=632 min=273 avg=288 std=200 std^2=40389
590               last=281 first=3672 max=632 min=273 avg=287 std=183 std^2=33666
591
592
593 config RING_BUFFER_BENCHMARK
594         tristate "Ring buffer benchmark stress tester"
595         depends on RING_BUFFER
596         help
597           This option creates a test to stress the ring buffer and benchmark it.
598           It creates its own ring buffer such that it will not interfere with
599           any other users of the ring buffer (such as ftrace). It then creates
600           a producer and consumer that will run for 10 seconds and sleep for
601           10 seconds. Each interval it will print out the number of events
602           it recorded and give a rough estimate of how long each iteration took.
603
604           It does not disable interrupts or raise its priority, so it may be
605           affected by processes that are running.
606
607           If unsure, say N.
608
609 config RING_BUFFER_STARTUP_TEST
610        bool "Ring buffer startup self test"
611        depends on RING_BUFFER
612        help
613          Run a simple self test on the ring buffer on boot up. Late in the
614          kernel boot sequence, the test will start that kicks off
615          a thread per cpu. Each thread will write various size events
616          into the ring buffer. Another thread is created to send IPIs
617          to each of the threads, where the IPI handler will also write
618          to the ring buffer, to test/stress the nesting ability.
619          If any anomalies are discovered, a warning will be displayed
620          and all ring buffers will be disabled.
621
622          The test runs for 10 seconds. This will slow your boot time
623          by at least 10 more seconds.
624
625          At the end of the test, statics and more checks are done.
626          It will output the stats of each per cpu buffer. What
627          was written, the sizes, what was read, what was lost, and
628          other similar details.
629
630          If unsure, say N
631
632 config TRACE_ENUM_MAP_FILE
633        bool "Show enum mappings for trace events"
634        depends on TRACING
635        help
636         The "print fmt" of the trace events will show the enum names instead
637         of their values. This can cause problems for user space tools that
638         use this string to parse the raw data as user space does not know
639         how to convert the string to its value.
640
641         To fix this, there's a special macro in the kernel that can be used
642         to convert the enum into its value. If this macro is used, then the
643         print fmt strings will have the enums converted to their values.
644
645         If something does not get converted properly, this option can be
646         used to show what enums the kernel tried to convert.
647
648         This option is for debugging the enum conversions. A file is created
649         in the tracing directory called "enum_map" that will show the enum
650         names matched with their values and what trace event system they
651         belong too.
652
653         Normally, the mapping of the strings to values will be freed after
654         boot up or module load. With this option, they will not be freed, as
655         they are needed for the "enum_map" file. Enabling this option will
656         increase the memory footprint of the running kernel.
657
658         If unsure, say N
659
660 config TRACING_EVENTS_GPIO
661         bool "Trace gpio events"
662         depends on GPIOLIB
663         default y
664         help
665           Enable tracing events for gpio subsystem
666
667 endif # FTRACE
668
669 endif # TRACING_SUPPORT
670