The trace-cmd(1) record command will set up the Ftrace Linux kernel
tracer to record the specified plugins or events that happen while
the command executes. If no command is given, then it will record
until the user hits Ctrl-C.
The record command of trace-cmd will set up the Ftrace tracer to
start tracing the various events or plugins that are given on the
command line. It will then create a number of tracing processes (one
per CPU) that will start recording from the kernel ring buffer
straight into temporary files. When the command is complete (or
Ctrl-C is hit) all the files will be combined into a trace.dat file
that can later be read (see trace-cmd-report(1)).
Specify a trace plugin. Plugins are special Ftrace tracers that
usually do more than just trace an event. Common plugins are
function, function_graph, preemptirqsoff, irqsoff, preemptoff,
and wakeup. A plugin must be supported by the running kernel. To
see a list of available plugins, see trace-cmd-list(1).
Specify an event to trace. Various static trace points have been
added to the Linux kernel. They are grouped by subsystem where
you can enable all events of a given subsystem or specify
specific events to be enabled. The event is of the format
"subsystem:event-name". You can also just specify the subsystem
without the :event-name or the event-name without the
"subsystem:". Using "-e sched_switch" will enable the
"sched_switch" event where as, "-e sched" will enable all events
under the "sched" subsystem.
The 'event' can also contain glob expressions. That is, "*stat*" will
select all events (or subsystems) that have the characters "stat" in their
The keyword 'all' can be used to enable all events.
Every event that is being recorded has its output format file
saved in the output file to be able to display it later. But if
other events are enabled in the trace without trace-cmd’s
knowledge, the formats of those events will not be recorded and
trace-cmd report will not be able to display them. If this is the
case, then specify the -a option and the format for all events in
the system will be saved.
Enable a stacktrace on each event. For example:
<idle>-0  58549.289091: sched_switch: kworker/0:1:0  R ==> trace-cmd:2603 
<idle>-0  58549.289092: kernel_stack: <stack trace>
=> schedule (ffffffff814b260e)
=> cpu_idle (ffffffff8100a38c)
=> start_secondary (ffffffff814ab828)
Enable a stack trace on all functions. Note this is only
applicable for the "function" plugin tracer, and will only take
effect if the -l option is used and succeeds in limiting
functions. If the function tracer is not filtered, and the stack
trace is enabled, you can live lock the machine.
Specify a filter for the previous event. This must come after a
-e. This will filter what events get recorded based on the
content of the event. Filtering is passed to the kernel directly
so what filtering is allowed may depend on what version of the
kernel you have. Basically, it will let you use C notation to
check if an event should be processed or not.
==, >=, <=, >, <, &, |, && and ||
The above are usually safe to use to compare fields.
Specify a trigger for the previous event. This must come after a
-e. This will add a given trigger to the given event. To only
enable the trigger and not the event itself, then place the event
after the -v option.
See Documentation/trace/events.txt in the Linux kernel source for more
information on triggers.
This will cause all events specified after it on the command line
to not be traced. This is useful for selecting a subsystem to be
traced but to leave out various events. For Example: "-e sched -v
-e "*stat\*"" will enable all events in the sched subsystem
except those that have "stat" in their names.
Note: the *-v* option was taken from the way grep(1) inverts the following
This will filter only the executable that is given on the command
line. If no command is given, then it will filter itself (pretty
pointless). Using -F will let you trace only events that are
caused by the given command.
Similar to -F but lets you specify a process ID to trace.
Used with either -F to trace the process' children too.
Set the trace clock to "clock".
Use trace-cmd(1) list -C to see what clocks are available.
By default, trace-cmd report will create a trace.dat file. You
can specify a different file to write to with the -o option.
This will limit the function and function_graph tracers to only
trace the given function name. More than one -l may be specified
on the command line to trace more than one function. The limited
use of glob expressions are also allowed. These are match* to
only filter functions that start with match. *match to only
filter functions that end with match. *match\* to only filter on
functions that contain match.
This option is for the function_graph plugin. It will graph the
given function. That is, it will only trace the function and all
functions that it calls. You can have more than one -g on the
This has the opposite effect of -l. The function given with the
-n option will not be traced. This takes precedence, that is, if
you include the same function for both -n and -l, it will not be
Some tracer plugins enable the function tracer by default. Like
the latency tracers. This option prevents the function tracer
from being enabled at start up.
The option -d will try to use the function-trace option to
disable the function tracer (if available), otherwise it defaults
to the proc file: /proc/sys/kernel/ftrace_enabled, but will not
touch it if the function-trace option is available. The -D option
will disable both the ftrace_enabled proc file as well as the
function-trace option if it exists.
Note, this disable function tracing for all users, which includes users
outside of ftrace tracers (stack_tracer, perf, etc).
Ftrace has various options that can be enabled or disabled. This
allows you to set them. Appending the text no to an option
disables it. For example: "-O nograph-time" will disable the
"graph-time" Ftrace option.
The processes that trace-cmd creates to record from the ring
buffer need to wake up to do the recording. Setting the interval
to zero will cause the processes to wakeup every time new data is
written into the buffer. But since Ftrace is recording kernel
activity, the act of this processes going back to sleep may cause
new events into the ring buffer which will wake the process back
up. This will needlessly add extra data into the ring buffer.
The 'interval' metric is microseconds. The default is set to 1000 (1 ms).
This is the time each recording process will sleep before waking up to
record any new data that was written to the ring buffer.
The priority to run the capture threads at. In a busy system the
trace capturing threads may be staved and events can be lost.
This increases the priority of those threads to the real time
(FIFO) priority. But use this option with care, it can also
change the behaviour of the system being traced.
This sets the ring buffer size to size kilobytes. Because the
Ftrace ring buffer is per CPU, this size is the size of each per
CPU ring buffer inside the kernel. Using "-b 10000" on a machine
with 4 CPUs will make Ftrace have a total buffer size of 40 Megs.
If the kernel supports multiple buffers, this will add a buffer
with the given name. If the buffer name already exists, that
buffer is just reset and will not be deleted at the end of record
execution. If the buffer is created, it will be removed at the
end of execution (unless the -k is set, or start command was
After a buffer name is stated, all events added after that will be
associated with that buffer. If no buffer is specified, or an event
is specified before a buffer name, it will be associated with the
main (toplevel) buffer.
trace-cmd record -e sched -B block -e block -B time -e timer sleep 1
The above is will enable all sched events in the main buffer. It will
then create a 'block' buffer instance and enable all block events within
that buffer. A 'time' buffer instance is created and all timer events
will be enabled for that event.
The max size in kilobytes that a per cpu buffer should be. Note,
due to rounding to page size, the number may not be totally
correct. Also, this is performed by switching between two buffers
that are half the given size thus the output may not be of the
given size even if much more was written.
Use this to prevent running out of diskspace for long runs.
Set the cpumask for to trace. It only affects the last buffer
instance given. If supplied before any buffer instance, then it
affects the main buffer. The value supplied must be a hex number.
trace-cmd record -p function -M c -B events13 -e all -M 5
If the -M is left out, then the mask stays the same. To enable all
CPUs, pass in a value of '-1'.
By default, when trace-cmd is finished tracing, it will reset the
buffers and disable all the tracing that it enabled. This option
keeps trace-cmd from disabling the tracer and reseting the
buffer. This option is useful for debugging trace-cmd.
Note: usually trace-cmd will set the "tracing_on" file back to what it
was before it was called. This option will leave that file set to zero.
By default, if an event is listed that trace-cmd does not find,
it will exit with an error. This option will just ignore events
that are listed on the command line but are not found on the
If another machine is running "trace-cmd listen", this option is
used to have the data sent to that machine with UDP packets.
Instead of writing to an output file, the data is sent off to a
remote box. This is ideal for embedded machines with little
storage, or having a single machine that will keep all the data
in a single repository.
Note: This option is not supported with latency tracer plugins:
wakeup, wakeup_rt, irqsoff, preemptoff and preemptirqsoff
This option is used with -N, when there’s a need to send the live
data with TCP packets instead of UDP. Although TCP is not nearly
as fast as sending the UDP packets, but it may be needed if the
network is not that reliable, the amount of data is not that
intensive, and a guarantee is needed that all traced information
is transfered successfully.
With the --date option, "trace-cmd" will write timestamps into
the trace buffer after it has finished recording. It will then
map the timestamp to gettimeofday which will allow wall time
output from the timestamps reading the created trace.dat file.
Set the maximum depth the function_graph tracer will trace into a
function. A value of one will only show where userspace enters
the kernel but not any functions called in the kernel. The
default is zero, which means no limit.
With the --profile option, "trace-cmd" will enable tracing that
can be used with trace-cmd-report(1) --profile option. If a
tracer -p is not set, and function graph depth is supported by
the kernel, then the function_graph tracer will be enabled with a
depth of one (only show where userspace enters into the kernel).
It will also enable various tracepoints with stack tracing such
that the report can show where tasks have been blocked for the
See trace-cmd-profile(1) for more details and examples.
Add custom event matching to connect any two events together.
When not used with --profile, it will save the parameter and this
will be used by trace-cmd report --profile, too. That is:
trace-cmd record -H hrtimer_expire_entry,hrtimer/hrtimer_expire_exit,hrtimer,sp
trace-cmd report --profile
Will profile hrtimer_expire_entry and hrtimer_expire_ext times.
See trace-cmd-profile(1) for format.
Add an offset for the timestamp in the trace.dat file. This will
add a offset option into the trace.dat file such that a trace-cmd
report will offset all the timestamps of the events by the given
offset. The offset is in raw units. That is, if the event
timestamps are in nanoseconds the offset will also be in
nanoseconds even if the displayed units are in microseconds.
Have output go to stderr instead of stdout, but the output of the
command executed will not be changed. This is useful if you want
to monitor the output of the command being executed, but not see
the output from trace-cmd.
This page is part of the trace-cmd (a front-end for Ftrace) project.
Information about the project can be found at [unknown -- if you
know, please contact email@example.com] If you have a bug report for
this manual page, send it to Steven Rostedt <firstname.lastname@example.org>.
This page was obtained from the project's upstream Git repository
on 2017-03-13. If you discover any rendering problems in this HTML
version of the page, or you believe there is a better or more up-to-
date source for the page, or you have corrections or improvements to
the information in this COLOPHON (which is not part of the original
manual page), send a mail to email@example.com