Linux kernel mirror (for testing) git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
kernel os linux

tracing: Add documentation for trace event triggers

Provide a basic overview of trace event triggers and document the
available trigger commands, along with a few simple examples.

Link: http://lkml.kernel.org/r/2595dd9196d7b553049611f2a3f849ca75d650a2.1382622043.git.tom.zanussi@linux.intel.com

Signed-off-by: Tom Zanussi <tom.zanussi@linux.intel.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>

authored by

Tom Zanussi and committed by
Steven Rostedt
ac38fb85 bac5fb97

+207
+207
Documentation/trace/events.txt
··· 287 287 prev_pid == 0 288 288 # cat sched_wakeup/filter 289 289 common_pid == 0 290 + 291 + 6. Event triggers 292 + ================= 293 + 294 + Trace events can be made to conditionally invoke trigger 'commands' 295 + which can take various forms and are described in detail below; 296 + examples would be enabling or disabling other trace events or invoking 297 + a stack trace whenever the trace event is hit. Whenever a trace event 298 + with attached triggers is invoked, the set of trigger commands 299 + associated with that event is invoked. Any given trigger can 300 + additionally have an event filter of the same form as described in 301 + section 5 (Event filtering) associated with it - the command will only 302 + be invoked if the event being invoked passes the associated filter. 303 + If no filter is associated with the trigger, it always passes. 304 + 305 + Triggers are added to and removed from a particular event by writing 306 + trigger expressions to the 'trigger' file for the given event. 307 + 308 + A given event can have any number of triggers associated with it, 309 + subject to any restrictions that individual commands may have in that 310 + regard. 311 + 312 + Event triggers are implemented on top of "soft" mode, which means that 313 + whenever a trace event has one or more triggers associated with it, 314 + the event is activated even if it isn't actually enabled, but is 315 + disabled in a "soft" mode. That is, the tracepoint will be called, 316 + but just will not be traced, unless of course it's actually enabled. 317 + This scheme allows triggers to be invoked even for events that aren't 318 + enabled, and also allows the current event filter implementation to be 319 + used for conditionally invoking triggers. 320 + 321 + The syntax for event triggers is roughly based on the syntax for 322 + set_ftrace_filter 'ftrace filter commands' (see the 'Filter commands' 323 + section of Documentation/trace/ftrace.txt), but there are major 324 + differences and the implementation isn't currently tied to it in any 325 + way, so beware about making generalizations between the two. 326 + 327 + 6.1 Expression syntax 328 + --------------------- 329 + 330 + Triggers are added by echoing the command to the 'trigger' file: 331 + 332 + # echo 'command[:count] [if filter]' > trigger 333 + 334 + Triggers are removed by echoing the same command but starting with '!' 335 + to the 'trigger' file: 336 + 337 + # echo '!command[:count] [if filter]' > trigger 338 + 339 + The [if filter] part isn't used in matching commands when removing, so 340 + leaving that off in a '!' command will accomplish the same thing as 341 + having it in. 342 + 343 + The filter syntax is the same as that described in the 'Event 344 + filtering' section above. 345 + 346 + For ease of use, writing to the trigger file using '>' currently just 347 + adds or removes a single trigger and there's no explicit '>>' support 348 + ('>' actually behaves like '>>') or truncation support to remove all 349 + triggers (you have to use '!' for each one added.) 350 + 351 + 6.2 Supported trigger commands 352 + ------------------------------ 353 + 354 + The following commands are supported: 355 + 356 + - enable_event/disable_event 357 + 358 + These commands can enable or disable another trace event whenever 359 + the triggering event is hit. When these commands are registered, 360 + the other trace event is activated, but disabled in a "soft" mode. 361 + That is, the tracepoint will be called, but just will not be traced. 362 + The event tracepoint stays in this mode as long as there's a trigger 363 + in effect that can trigger it. 364 + 365 + For example, the following trigger causes kmalloc events to be 366 + traced when a read system call is entered, and the :1 at the end 367 + specifies that this enablement happens only once: 368 + 369 + # echo 'enable_event:kmem:kmalloc:1' > \ 370 + /sys/kernel/debug/tracing/events/syscalls/sys_enter_read/trigger 371 + 372 + The following trigger causes kmalloc events to stop being traced 373 + when a read system call exits. This disablement happens on every 374 + read system call exit: 375 + 376 + # echo 'disable_event:kmem:kmalloc' > \ 377 + /sys/kernel/debug/tracing/events/syscalls/sys_exit_read/trigger 378 + 379 + The format is: 380 + 381 + enable_event:<system>:<event>[:count] 382 + disable_event:<system>:<event>[:count] 383 + 384 + To remove the above commands: 385 + 386 + # echo '!enable_event:kmem:kmalloc:1' > \ 387 + /sys/kernel/debug/tracing/events/syscalls/sys_enter_read/trigger 388 + 389 + # echo '!disable_event:kmem:kmalloc' > \ 390 + /sys/kernel/debug/tracing/events/syscalls/sys_exit_read/trigger 391 + 392 + Note that there can be any number of enable/disable_event triggers 393 + per triggering event, but there can only be one trigger per 394 + triggered event. e.g. sys_enter_read can have triggers enabling both 395 + kmem:kmalloc and sched:sched_switch, but can't have two kmem:kmalloc 396 + versions such as kmem:kmalloc and kmem:kmalloc:1 or 'kmem:kmalloc if 397 + bytes_req == 256' and 'kmem:kmalloc if bytes_alloc == 256' (they 398 + could be combined into a single filter on kmem:kmalloc though). 399 + 400 + - stacktrace 401 + 402 + This command dumps a stacktrace in the trace buffer whenever the 403 + triggering event occurs. 404 + 405 + For example, the following trigger dumps a stacktrace every time the 406 + kmalloc tracepoint is hit: 407 + 408 + # echo 'stacktrace' > \ 409 + /sys/kernel/debug/tracing/events/kmem/kmalloc/trigger 410 + 411 + The following trigger dumps a stacktrace the first 5 times a kmalloc 412 + request happens with a size >= 64K 413 + 414 + # echo 'stacktrace:5 if bytes_req >= 65536' > \ 415 + /sys/kernel/debug/tracing/events/kmem/kmalloc/trigger 416 + 417 + The format is: 418 + 419 + stacktrace[:count] 420 + 421 + To remove the above commands: 422 + 423 + # echo '!stacktrace' > \ 424 + /sys/kernel/debug/tracing/events/kmem/kmalloc/trigger 425 + 426 + # echo '!stacktrace:5 if bytes_req >= 65536' > \ 427 + /sys/kernel/debug/tracing/events/kmem/kmalloc/trigger 428 + 429 + The latter can also be removed more simply by the following (without 430 + the filter): 431 + 432 + # echo '!stacktrace:5' > \ 433 + /sys/kernel/debug/tracing/events/kmem/kmalloc/trigger 434 + 435 + Note that there can be only one stacktrace trigger per triggering 436 + event. 437 + 438 + - snapshot 439 + 440 + This command causes a snapshot to be triggered whenever the 441 + triggering event occurs. 442 + 443 + The following command creates a snapshot every time a block request 444 + queue is unplugged with a depth > 1. If you were tracing a set of 445 + events or functions at the time, the snapshot trace buffer would 446 + capture those events when the trigger event occured: 447 + 448 + # echo 'snapshot if nr_rq > 1' > \ 449 + /sys/kernel/debug/tracing/events/block/block_unplug/trigger 450 + 451 + To only snapshot once: 452 + 453 + # echo 'snapshot:1 if nr_rq > 1' > \ 454 + /sys/kernel/debug/tracing/events/block/block_unplug/trigger 455 + 456 + To remove the above commands: 457 + 458 + # echo '!snapshot if nr_rq > 1' > \ 459 + /sys/kernel/debug/tracing/events/block/block_unplug/trigger 460 + 461 + # echo '!snapshot:1 if nr_rq > 1' > \ 462 + /sys/kernel/debug/tracing/events/block/block_unplug/trigger 463 + 464 + Note that there can be only one snapshot trigger per triggering 465 + event. 466 + 467 + - traceon/traceoff 468 + 469 + These commands turn tracing on and off when the specified events are 470 + hit. The parameter determines how many times the tracing system is 471 + turned on and off. If unspecified, there is no limit. 472 + 473 + The following command turns tracing off the first time a block 474 + request queue is unplugged with a depth > 1. If you were tracing a 475 + set of events or functions at the time, you could then examine the 476 + trace buffer to see the sequence of events that led up to the 477 + trigger event: 478 + 479 + # echo 'traceoff:1 if nr_rq > 1' > \ 480 + /sys/kernel/debug/tracing/events/block/block_unplug/trigger 481 + 482 + To always disable tracing when nr_rq > 1 : 483 + 484 + # echo 'traceoff if nr_rq > 1' > \ 485 + /sys/kernel/debug/tracing/events/block/block_unplug/trigger 486 + 487 + To remove the above commands: 488 + 489 + # echo '!traceoff:1 if nr_rq > 1' > \ 490 + /sys/kernel/debug/tracing/events/block/block_unplug/trigger 491 + 492 + # echo '!traceoff if nr_rq > 1' > \ 493 + /sys/kernel/debug/tracing/events/block/block_unplug/trigger 494 + 495 + Note that there can be only one traceon or traceoff trigger per 496 + triggering event.