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