Kconfig 15 KB

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