powerpc: Separate PACA fields for server CPUs
[deliverable/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
15 config HAVE_FUNCTION_TRACER
16 bool
17
18 config HAVE_FUNCTION_GRAPH_TRACER
19 bool
20
21 config HAVE_FUNCTION_TRACE_MCOUNT_TEST
22 bool
23 help
24 This gets selected when the arch tests the function_trace_stop
25 variable at the mcount call site. Otherwise, this variable
26 is tested by the called function.
27
28 config HAVE_DYNAMIC_FTRACE
29 bool
30
31 config HAVE_FTRACE_MCOUNT_RECORD
32 bool
33
34 config HAVE_HW_BRANCH_TRACER
35 bool
36
37 config HAVE_FTRACE_SYSCALLS
38 bool
39
40 config TRACER_MAX_TRACE
41 bool
42
43 config RING_BUFFER
44 bool
45
46 config FTRACE_NMI_ENTER
47 bool
48 depends on HAVE_FTRACE_NMI_ENTER
49 default y
50
51 config TRACING
52 bool
53 select DEBUG_FS
54 select RING_BUFFER
55 select STACKTRACE if STACKTRACE_SUPPORT
56 select TRACEPOINTS
57 select NOP_TRACER
58 select BINARY_PRINTF
59
60 #
61 # Minimum requirements an architecture has to meet for us to
62 # be able to offer generic tracing facilities:
63 #
64 config TRACING_SUPPORT
65 bool
66 # PPC32 has no irqflags tracing support, but it can use most of the
67 # tracers anyway, they were tested to build and work. Note that new
68 # exceptions to this list aren't welcomed, better implement the
69 # irqflags tracing for your architecture.
70 depends on TRACE_IRQFLAGS_SUPPORT || PPC32
71 depends on STACKTRACE_SUPPORT
72 default y
73
74 if TRACING_SUPPORT
75
76 menu "Tracers"
77
78 config FUNCTION_TRACER
79 bool "Kernel Function Tracer"
80 depends on HAVE_FUNCTION_TRACER
81 select FRAME_POINTER
82 select KALLSYMS
83 select TRACING
84 select CONTEXT_SWITCH_TRACER
85 help
86 Enable the kernel to trace every kernel function. This is done
87 by using a compiler feature to insert a small, 5-byte No-Operation
88 instruction to the beginning of every kernel function, which NOP
89 sequence is then dynamically patched into a tracer call when
90 tracing is enabled by the administrator. If it's runtime disabled
91 (the bootup default), then the overhead of the instructions is very
92 small and not measurable even in micro-benchmarks.
93
94 config FUNCTION_GRAPH_TRACER
95 bool "Kernel Function Graph Tracer"
96 depends on HAVE_FUNCTION_GRAPH_TRACER
97 depends on FUNCTION_TRACER
98 default y
99 help
100 Enable the kernel to trace a function at both its return
101 and its entry.
102 Its first purpose is to trace the duration of functions and
103 draw a call graph for each thread with some information like
104 the return value. This is done by setting the current return
105 address on the current task structure into a stack of calls.
106
107 config IRQSOFF_TRACER
108 bool "Interrupts-off Latency Tracer"
109 default n
110 depends on TRACE_IRQFLAGS_SUPPORT
111 depends on GENERIC_TIME
112 select TRACE_IRQFLAGS
113 select TRACING
114 select TRACER_MAX_TRACE
115 help
116 This option measures the time spent in irqs-off critical
117 sections, with microsecond accuracy.
118
119 The default measurement method is a maximum search, which is
120 disabled by default and can be runtime (re-)started
121 via:
122
123 echo 0 > /debugfs/tracing/tracing_max_latency
124
125 (Note that kernel size and overhead increases with this option
126 enabled. This option and the preempt-off timing option can be
127 used together or separately.)
128
129 config PREEMPT_TRACER
130 bool "Preemption-off Latency Tracer"
131 default n
132 depends on GENERIC_TIME
133 depends on PREEMPT
134 select TRACING
135 select TRACER_MAX_TRACE
136 help
137 This option measures the time spent in preemption off critical
138 sections, with microsecond accuracy.
139
140 The default measurement method is a maximum search, which is
141 disabled by default and can be runtime (re-)started
142 via:
143
144 echo 0 > /debugfs/tracing/tracing_max_latency
145
146 (Note that kernel size and overhead increases with this option
147 enabled. This option and the irqs-off timing option can be
148 used together or separately.)
149
150 config SYSPROF_TRACER
151 bool "Sysprof Tracer"
152 depends on X86
153 select TRACING
154 select CONTEXT_SWITCH_TRACER
155 help
156 This tracer provides the trace needed by the 'Sysprof' userspace
157 tool.
158
159 config SCHED_TRACER
160 bool "Scheduling Latency Tracer"
161 select TRACING
162 select CONTEXT_SWITCH_TRACER
163 select TRACER_MAX_TRACE
164 help
165 This tracer tracks the latency of the highest priority task
166 to be scheduled in, starting from the point it has woken up.
167
168 config CONTEXT_SWITCH_TRACER
169 bool "Trace process context switches"
170 select TRACING
171 select MARKERS
172 help
173 This tracer gets called from the context switch and records
174 all switching of tasks.
175
176 config EVENT_TRACER
177 bool "Trace various events in the kernel"
178 select TRACING
179 help
180 This tracer hooks to various trace points in the kernel
181 allowing the user to pick and choose which trace point they
182 want to trace.
183
184 config FTRACE_SYSCALLS
185 bool "Trace syscalls"
186 depends on HAVE_FTRACE_SYSCALLS
187 select TRACING
188 select KALLSYMS
189 help
190 Basic tracer to catch the syscall entry and exit events.
191
192 config BOOT_TRACER
193 bool "Trace boot initcalls"
194 select TRACING
195 select CONTEXT_SWITCH_TRACER
196 help
197 This tracer helps developers to optimize boot times: it records
198 the timings of the initcalls and traces key events and the identity
199 of tasks that can cause boot delays, such as context-switches.
200
201 Its aim is to be parsed by the /scripts/bootgraph.pl tool to
202 produce pretty graphics about boot inefficiencies, giving a visual
203 representation of the delays during initcalls - but the raw
204 /debug/tracing/trace text output is readable too.
205
206 You must pass in ftrace=initcall to the kernel command line
207 to enable this on bootup.
208
209 config TRACE_BRANCH_PROFILING
210 bool "Trace likely/unlikely profiler"
211 select TRACING
212 help
213 This tracer profiles all the the likely and unlikely macros
214 in the kernel. It will display the results in:
215
216 /debugfs/tracing/profile_annotated_branch
217
218 Note: this will add a significant overhead, only turn this
219 on if you need to profile the system's use of these macros.
220
221 Say N if unsure.
222
223 config PROFILE_ALL_BRANCHES
224 bool "Profile all if conditionals"
225 depends on TRACE_BRANCH_PROFILING
226 help
227 This tracer profiles all branch conditions. Every if ()
228 taken in the kernel is recorded whether it hit or miss.
229 The results will be displayed in:
230
231 /debugfs/tracing/profile_branch
232
233 This configuration, when enabled, will impose a great overhead
234 on the system. This should only be enabled when the system
235 is to be analyzed
236
237 Say N if unsure.
238
239 config TRACING_BRANCHES
240 bool
241 help
242 Selected by tracers that will trace the likely and unlikely
243 conditions. This prevents the tracers themselves from being
244 profiled. Profiling the tracing infrastructure can only happen
245 when the likelys and unlikelys are not being traced.
246
247 config BRANCH_TRACER
248 bool "Trace likely/unlikely instances"
249 depends on TRACE_BRANCH_PROFILING
250 select TRACING_BRANCHES
251 help
252 This traces the events of likely and unlikely condition
253 calls in the kernel. The difference between this and the
254 "Trace likely/unlikely profiler" is that this is not a
255 histogram of the callers, but actually places the calling
256 events into a running trace buffer to see when and where the
257 events happened, as well as their results.
258
259 Say N if unsure.
260
261 config POWER_TRACER
262 bool "Trace power consumption behavior"
263 depends on X86
264 select TRACING
265 help
266 This tracer helps developers to analyze and optimize the kernels
267 power management decisions, specifically the C-state and P-state
268 behavior.
269
270
271 config STACK_TRACER
272 bool "Trace max stack"
273 depends on HAVE_FUNCTION_TRACER
274 select FUNCTION_TRACER
275 select STACKTRACE
276 select KALLSYMS
277 help
278 This special tracer records the maximum stack footprint of the
279 kernel and displays it in debugfs/tracing/stack_trace.
280
281 This tracer works by hooking into every function call that the
282 kernel executes, and keeping a maximum stack depth value and
283 stack-trace saved. If this is configured with DYNAMIC_FTRACE
284 then it will not have any overhead while the stack tracer
285 is disabled.
286
287 To enable the stack tracer on bootup, pass in 'stacktrace'
288 on the kernel command line.
289
290 The stack tracer can also be enabled or disabled via the
291 sysctl kernel.stack_tracer_enabled
292
293 Say N if unsure.
294
295 config HW_BRANCH_TRACER
296 depends on HAVE_HW_BRANCH_TRACER
297 bool "Trace hw branches"
298 select TRACING
299 help
300 This tracer records all branches on the system in a circular
301 buffer giving access to the last N branches for each cpu.
302
303 config KMEMTRACE
304 bool "Trace SLAB allocations"
305 select TRACING
306 help
307 kmemtrace provides tracing for slab allocator functions, such as
308 kmalloc, kfree, kmem_cache_alloc, kmem_cache_free etc.. Collected
309 data is then fed to the userspace application in order to analyse
310 allocation hotspots, internal fragmentation and so on, making it
311 possible to see how well an allocator performs, as well as debug
312 and profile kernel code.
313
314 This requires an userspace application to use. See
315 Documentation/trace/kmemtrace.txt for more information.
316
317 Saying Y will make the kernel somewhat larger and slower. However,
318 if you disable kmemtrace at run-time or boot-time, the performance
319 impact is minimal (depending on the arch the kernel is built for).
320
321 If unsure, say N.
322
323 config WORKQUEUE_TRACER
324 bool "Trace workqueues"
325 select TRACING
326 help
327 The workqueue tracer provides some statistical informations
328 about each cpu workqueue thread such as the number of the
329 works inserted and executed since their creation. It can help
330 to evaluate the amount of work each of them have to perform.
331 For example it can help a developer to decide whether he should
332 choose a per cpu workqueue instead of a singlethreaded one.
333
334 config BLK_DEV_IO_TRACE
335 bool "Support for tracing block io actions"
336 depends on SYSFS
337 depends on BLOCK
338 select RELAY
339 select DEBUG_FS
340 select TRACEPOINTS
341 select TRACING
342 select STACKTRACE
343 help
344 Say Y here if you want to be able to trace the block layer actions
345 on a given queue. Tracing allows you to see any traffic happening
346 on a block device queue. For more information (and the userspace
347 support tools needed), fetch the blktrace tools from:
348
349 git://git.kernel.dk/blktrace.git
350
351 Tracing also is possible using the ftrace interface, e.g.:
352
353 echo 1 > /sys/block/sda/sda1/trace/enable
354 echo blk > /sys/kernel/debug/tracing/current_tracer
355 cat /sys/kernel/debug/tracing/trace_pipe
356
357 If unsure, say N.
358
359 config DYNAMIC_FTRACE
360 bool "enable/disable ftrace tracepoints dynamically"
361 depends on FUNCTION_TRACER
362 depends on HAVE_DYNAMIC_FTRACE
363 default y
364 help
365 This option will modify all the calls to ftrace dynamically
366 (will patch them out of the binary image and replaces them
367 with a No-Op instruction) as they are called. A table is
368 created to dynamically enable them again.
369
370 This way a CONFIG_FUNCTION_TRACER kernel is slightly larger, but otherwise
371 has native performance as long as no tracing is active.
372
373 The changes to the code are done by a kernel thread that
374 wakes up once a second and checks to see if any ftrace calls
375 were made. If so, it runs stop_machine (stops all CPUS)
376 and modifies the code to jump over the call to ftrace.
377
378 config FTRACE_MCOUNT_RECORD
379 def_bool y
380 depends on DYNAMIC_FTRACE
381 depends on HAVE_FTRACE_MCOUNT_RECORD
382
383 config FTRACE_SELFTEST
384 bool
385
386 config FTRACE_STARTUP_TEST
387 bool "Perform a startup test on ftrace"
388 depends on TRACING
389 select FTRACE_SELFTEST
390 help
391 This option performs a series of startup tests on ftrace. On bootup
392 a series of tests are made to verify that the tracer is
393 functioning properly. It will do tests on all the configured
394 tracers of ftrace.
395
396 config MMIOTRACE
397 bool "Memory mapped IO tracing"
398 depends on HAVE_MMIOTRACE_SUPPORT && PCI
399 select TRACING
400 help
401 Mmiotrace traces Memory Mapped I/O access and is meant for
402 debugging and reverse engineering. It is called from the ioremap
403 implementation and works via page faults. Tracing is disabled by
404 default and can be enabled at run-time.
405
406 See Documentation/trace/mmiotrace.txt.
407 If you are not helping to develop drivers, say N.
408
409 config MMIOTRACE_TEST
410 tristate "Test module for mmiotrace"
411 depends on MMIOTRACE && m
412 help
413 This is a dumb module for testing mmiotrace. It is very dangerous
414 as it will write garbage to IO memory starting at a given address.
415 However, it should be safe to use on e.g. unused portion of VRAM.
416
417 Say N, unless you absolutely know what you are doing.
418
419 endmenu
420
421 endif # TRACING_SUPPORT
422
This page took 0.039924 seconds and 5 git commands to generate.