• Home
  • Line#
  • Scopes#
  • Navigate#
  • Raw
  • Download
1perf-stat(1)
2============
3
4NAME
5----
6perf-stat - Run a command and gather performance counter statistics
7
8SYNOPSIS
9--------
10[verse]
11'perf stat' [-e <EVENT> | --event=EVENT] [-a] <command>
12'perf stat' [-e <EVENT> | --event=EVENT] [-a] -- <command> [<options>]
13'perf stat' [-e <EVENT> | --event=EVENT] [-a] record [-o file] -- <command> [<options>]
14'perf stat' report [-i file]
15
16DESCRIPTION
17-----------
18This command runs a command and gathers performance counter statistics
19from it.
20
21
22OPTIONS
23-------
24<command>...::
25	Any command you can specify in a shell.
26
27record::
28	See STAT RECORD.
29
30report::
31	See STAT REPORT.
32
33-e::
34--event=::
35	Select the PMU event. Selection can be:
36
37	- a symbolic event name (use 'perf list' to list all events)
38
39	- a raw PMU event (eventsel+umask) in the form of rNNN where NNN is a
40	  hexadecimal event descriptor.
41
42        - a symbolic or raw PMU event followed by an optional colon
43	  and a list of event modifiers, e.g., cpu-cycles:p.  See the
44	  linkperf:perf-list[1] man page for details on event modifiers.
45
46	- a symbolically formed event like 'pmu/param1=0x3,param2/' where
47	  param1 and param2 are defined as formats for the PMU in
48	  /sys/bus/event_source/devices/<pmu>/format/*
49
50	  'percore' is a event qualifier that sums up the event counts for both
51	  hardware threads in a core. For example:
52	  perf stat -A -a -e cpu/event,percore=1/,otherevent ...
53
54	- a symbolically formed event like 'pmu/config=M,config1=N,config2=K/'
55	  where M, N, K are numbers (in decimal, hex, octal format).
56	  Acceptable values for each of 'config', 'config1' and 'config2'
57	  parameters are defined by corresponding entries in
58	  /sys/bus/event_source/devices/<pmu>/format/*
59
60	Note that the last two syntaxes support prefix and glob matching in
61	the PMU name to simplify creation of events across multiple instances
62	of the same type of PMU in large systems (e.g. memory controller PMUs).
63	Multiple PMU instances are typical for uncore PMUs, so the prefix
64	'uncore_' is also ignored when performing this match.
65
66
67-i::
68--no-inherit::
69        child tasks do not inherit counters
70-p::
71--pid=<pid>::
72        stat events on existing process id (comma separated list)
73
74-t::
75--tid=<tid>::
76        stat events on existing thread id (comma separated list)
77
78ifdef::HAVE_LIBPFM[]
79--pfm-events events::
80Select a PMU event using libpfm4 syntax (see http://perfmon2.sf.net)
81including support for event filters. For example '--pfm-events
82inst_retired:any_p:u:c=1:i'. More than one event can be passed to the
83option using the comma separator. Hardware events and generic hardware
84events cannot be mixed together. The latter must be used with the -e
85option. The -e option and this one can be mixed and matched.  Events
86can be grouped using the {} notation.
87endif::HAVE_LIBPFM[]
88
89-a::
90--all-cpus::
91        system-wide collection from all CPUs (default if no target is specified)
92
93--no-scale::
94	Don't scale/normalize counter values
95
96-d::
97--detailed::
98	print more detailed statistics, can be specified up to 3 times
99
100	   -d:          detailed events, L1 and LLC data cache
101        -d -d:     more detailed events, dTLB and iTLB events
102     -d -d -d:     very detailed events, adding prefetch events
103
104-r::
105--repeat=<n>::
106	repeat command and print average + stddev (max: 100). 0 means forever.
107
108-B::
109--big-num::
110        print large numbers with thousands' separators according to locale.
111	Enabled by default. Use "--no-big-num" to disable.
112	Default setting can be changed with "perf config stat.big-num=false".
113
114-C::
115--cpu=::
116Count only on the list of CPUs provided. Multiple CPUs can be provided as a
117comma-separated list with no space: 0,1. Ranges of CPUs are specified with -: 0-2.
118In per-thread mode, this option is ignored. The -a option is still necessary
119to activate system-wide monitoring. Default is to count on all CPUs.
120
121-A::
122--no-aggr::
123Do not aggregate counts across all monitored CPUs.
124
125-n::
126--null::
127        null run - don't start any counters
128
129-v::
130--verbose::
131        be more verbose (show counter open errors, etc)
132
133-x SEP::
134--field-separator SEP::
135print counts using a CSV-style output to make it easy to import directly into
136spreadsheets. Columns are separated by the string specified in SEP.
137
138--table:: Display time for each run (-r option), in a table format, e.g.:
139
140  $ perf stat --null -r 5 --table perf bench sched pipe
141
142   Performance counter stats for 'perf bench sched pipe' (5 runs):
143
144             # Table of individual measurements:
145             5.189 (-0.293) #
146             5.189 (-0.294) #
147             5.186 (-0.296) #
148             5.663 (+0.181) ##
149             6.186 (+0.703) ####
150
151             # Final result:
152             5.483 +- 0.198 seconds time elapsed  ( +-  3.62% )
153
154-G name::
155--cgroup name::
156monitor only in the container (cgroup) called "name". This option is available only
157in per-cpu mode. The cgroup filesystem must be mounted. All threads belonging to
158container "name" are monitored when they run on the monitored CPUs. Multiple cgroups
159can be provided. Each cgroup is applied to the corresponding event, i.e., first cgroup
160to first event, second cgroup to second event and so on. It is possible to provide
161an empty cgroup (monitor all the time) using, e.g., -G foo,,bar. Cgroups must have
162corresponding events, i.e., they always refer to events defined earlier on the command
163line. If the user wants to track multiple events for a specific cgroup, the user can
164use '-e e1 -e e2 -G foo,foo' or just use '-e e1 -e e2 -G foo'.
165
166If wanting to monitor, say, 'cycles' for a cgroup and also for system wide, this
167command line can be used: 'perf stat -e cycles -G cgroup_name -a -e cycles'.
168
169--for-each-cgroup name::
170Expand event list for each cgroup in "name" (allow multiple cgroups separated
171by comma).  This has same effect that repeating -e option and -G option for
172each event x name.  This option cannot be used with -G/--cgroup option.
173
174-o file::
175--output file::
176Print the output into the designated file.
177
178--append::
179Append to the output file designated with the -o option. Ignored if -o is not specified.
180
181--log-fd::
182
183Log output to fd, instead of stderr.  Complementary to --output, and mutually exclusive
184with it.  --append may be used here.  Examples:
185     3>results  perf stat --log-fd 3          -- $cmd
186     3>>results perf stat --log-fd 3 --append -- $cmd
187
188--control=fifo:ctl-fifo[,ack-fifo]::
189--control=fd:ctl-fd[,ack-fd]::
190ctl-fifo / ack-fifo are opened and used as ctl-fd / ack-fd as follows.
191Listen on ctl-fd descriptor for command to control measurement ('enable': enable events,
192'disable': disable events). Measurements can be started with events disabled using
193--delay=-1 option. Optionally send control command completion ('ack\n') to ack-fd descriptor
194to synchronize with the controlling process. Example of bash shell script to enable and
195disable events during measurements:
196
197 #!/bin/bash
198
199 ctl_dir=/tmp/
200
201 ctl_fifo=${ctl_dir}perf_ctl.fifo
202 test -p ${ctl_fifo} && unlink ${ctl_fifo}
203 mkfifo ${ctl_fifo}
204 exec {ctl_fd}<>${ctl_fifo}
205
206 ctl_ack_fifo=${ctl_dir}perf_ctl_ack.fifo
207 test -p ${ctl_ack_fifo} && unlink ${ctl_ack_fifo}
208 mkfifo ${ctl_ack_fifo}
209 exec {ctl_fd_ack}<>${ctl_ack_fifo}
210
211 perf stat -D -1 -e cpu-cycles -a -I 1000       \
212           --control fd:${ctl_fd},${ctl_fd_ack} \
213           -- sleep 30 &
214 perf_pid=$!
215
216 sleep 5  && echo 'enable' >&${ctl_fd} && read -u ${ctl_fd_ack} e1 && echo "enabled(${e1})"
217 sleep 10 && echo 'disable' >&${ctl_fd} && read -u ${ctl_fd_ack} d1 && echo "disabled(${d1})"
218
219 exec {ctl_fd_ack}>&-
220 unlink ${ctl_ack_fifo}
221
222 exec {ctl_fd}>&-
223 unlink ${ctl_fifo}
224
225 wait -n ${perf_pid}
226 exit $?
227
228
229--pre::
230--post::
231	Pre and post measurement hooks, e.g.:
232
233perf stat --repeat 10 --null --sync --pre 'make -s O=defconfig-build/clean' -- make -s -j64 O=defconfig-build/ bzImage
234
235-I msecs::
236--interval-print msecs::
237Print count deltas every N milliseconds (minimum: 1ms)
238The overhead percentage could be high in some cases, for instance with small, sub 100ms intervals.  Use with caution.
239	example: 'perf stat -I 1000 -e cycles -a sleep 5'
240
241If the metric exists, it is calculated by the counts generated in this interval and the metric is printed after #.
242
243--interval-count times::
244Print count deltas for fixed number of times.
245This option should be used together with "-I" option.
246	example: 'perf stat -I 1000 --interval-count 2 -e cycles -a'
247
248--interval-clear::
249Clear the screen before next interval.
250
251--timeout msecs::
252Stop the 'perf stat' session and print count deltas after N milliseconds (minimum: 10 ms).
253This option is not supported with the "-I" option.
254	example: 'perf stat --time 2000 -e cycles -a'
255
256--metric-only::
257Only print computed metrics. Print them in a single line.
258Don't show any raw values. Not supported with --per-thread.
259
260--per-socket::
261Aggregate counts per processor socket for system-wide mode measurements.  This
262is a useful mode to detect imbalance between sockets.  To enable this mode,
263use --per-socket in addition to -a. (system-wide).  The output includes the
264socket number and the number of online processors on that socket. This is
265useful to gauge the amount of aggregation.
266
267--per-die::
268Aggregate counts per processor die for system-wide mode measurements.  This
269is a useful mode to detect imbalance between dies.  To enable this mode,
270use --per-die in addition to -a. (system-wide).  The output includes the
271die number and the number of online processors on that die. This is
272useful to gauge the amount of aggregation.
273
274--per-core::
275Aggregate counts per physical processor for system-wide mode measurements.  This
276is a useful mode to detect imbalance between physical cores.  To enable this mode,
277use --per-core in addition to -a. (system-wide).  The output includes the
278core number and the number of online logical processors on that physical processor.
279
280--per-thread::
281Aggregate counts per monitored threads, when monitoring threads (-t option)
282or processes (-p option).
283
284--per-node::
285Aggregate counts per NUMA nodes for system-wide mode measurements. This
286is a useful mode to detect imbalance between NUMA nodes. To enable this
287mode, use --per-node in addition to -a. (system-wide).
288
289-D msecs::
290--delay msecs::
291After starting the program, wait msecs before measuring (-1: start with events
292disabled). This is useful to filter out the startup phase of the program,
293which is often very different.
294
295-T::
296--transaction::
297
298Print statistics of transactional execution if supported.
299
300--metric-no-group::
301By default, events to compute a metric are placed in weak groups. The
302group tries to enforce scheduling all or none of the events. The
303--metric-no-group option places events outside of groups and may
304increase the chance of the event being scheduled - leading to more
305accuracy. However, as events may not be scheduled together accuracy
306for metrics like instructions per cycle can be lower - as both metrics
307may no longer be being measured at the same time.
308
309--metric-no-merge::
310By default metric events in different weak groups can be shared if one
311group contains all the events needed by another. In such cases one
312group will be eliminated reducing event multiplexing and making it so
313that certain groups of metrics sum to 100%. A downside to sharing a
314group is that the group may require multiplexing and so accuracy for a
315small group that need not have multiplexing is lowered. This option
316forbids the event merging logic from sharing events between groups and
317may be used to increase accuracy in this case.
318
319STAT RECORD
320-----------
321Stores stat data into perf data file.
322
323-o file::
324--output file::
325Output file name.
326
327STAT REPORT
328-----------
329Reads and reports stat data from perf data file.
330
331-i file::
332--input file::
333Input file name.
334
335--per-socket::
336Aggregate counts per processor socket for system-wide mode measurements.
337
338--per-die::
339Aggregate counts per processor die for system-wide mode measurements.
340
341--per-core::
342Aggregate counts per physical processor for system-wide mode measurements.
343
344-M::
345--metrics::
346Print metrics or metricgroups specified in a comma separated list.
347For a group all metrics from the group are added.
348The events from the metrics are automatically measured.
349See perf list output for the possble metrics and metricgroups.
350
351-A::
352--no-aggr::
353Do not aggregate counts across all monitored CPUs.
354
355--topdown::
356Print top down level 1 metrics if supported by the CPU. This allows to
357determine bottle necks in the CPU pipeline for CPU bound workloads,
358by breaking the cycles consumed down into frontend bound, backend bound,
359bad speculation and retiring.
360
361Frontend bound means that the CPU cannot fetch and decode instructions fast
362enough. Backend bound means that computation or memory access is the bottle
363neck. Bad Speculation means that the CPU wasted cycles due to branch
364mispredictions and similar issues. Retiring means that the CPU computed without
365an apparently bottleneck. The bottleneck is only the real bottleneck
366if the workload is actually bound by the CPU and not by something else.
367
368For best results it is usually a good idea to use it with interval
369mode like -I 1000, as the bottleneck of workloads can change often.
370
371This enables --metric-only, unless overridden with --no-metric-only.
372
373The following restrictions only apply to older Intel CPUs and Atom,
374on newer CPUs (IceLake and later) TopDown can be collected for any thread:
375
376The top down metrics are collected per core instead of per
377CPU thread. Per core mode is automatically enabled
378and -a (global monitoring) is needed, requiring root rights or
379perf.perf_event_paranoid=-1.
380
381Topdown uses the full Performance Monitoring Unit, and needs
382disabling of the NMI watchdog (as root):
383echo 0 > /proc/sys/kernel/nmi_watchdog
384for best results. Otherwise the bottlenecks may be inconsistent
385on workload with changing phases.
386
387To interpret the results it is usually needed to know on which
388CPUs the workload runs on. If needed the CPUs can be forced using
389taskset.
390
391--no-merge::
392Do not merge results from same PMUs.
393
394When multiple events are created from a single event specification,
395stat will, by default, aggregate the event counts and show the result
396in a single row. This option disables that behavior and shows
397the individual events and counts.
398
399Multiple events are created from a single event specification when:
4001. Prefix or glob matching is used for the PMU name.
4012. Aliases, which are listed immediately after the Kernel PMU events
402   by perf list, are used.
403
404--smi-cost::
405Measure SMI cost if msr/aperf/ and msr/smi/ events are supported.
406
407During the measurement, the /sys/device/cpu/freeze_on_smi will be set to
408freeze core counters on SMI.
409The aperf counter will not be effected by the setting.
410The cost of SMI can be measured by (aperf - unhalted core cycles).
411
412In practice, the percentages of SMI cycles is very useful for performance
413oriented analysis. --metric_only will be applied by default.
414The output is SMI cycles%, equals to (aperf - unhalted core cycles) / aperf
415
416Users who wants to get the actual value can apply --no-metric-only.
417
418--all-kernel::
419Configure all used events to run in kernel space.
420
421--all-user::
422Configure all used events to run in user space.
423
424--percore-show-thread::
425The event modifier "percore" has supported to sum up the event counts
426for all hardware threads in a core and show the counts per core.
427
428This option with event modifier "percore" enabled also sums up the event
429counts for all hardware threads in a core but show the sum counts per
430hardware thread. This is essentially a replacement for the any bit and
431convenient for post processing.
432
433--summary::
434Print summary for interval mode (-I).
435
436EXAMPLES
437--------
438
439$ perf stat -- make
440
441   Performance counter stats for 'make':
442
443        83723.452481      task-clock:u (msec)       #    1.004 CPUs utilized
444                   0      context-switches:u        #    0.000 K/sec
445                   0      cpu-migrations:u          #    0.000 K/sec
446           3,228,188      page-faults:u             #    0.039 M/sec
447     229,570,665,834      cycles:u                  #    2.742 GHz
448     313,163,853,778      instructions:u            #    1.36  insn per cycle
449      69,704,684,856      branches:u                #  832.559 M/sec
450       2,078,861,393      branch-misses:u           #    2.98% of all branches
451
452        83.409183620 seconds time elapsed
453
454        74.684747000 seconds user
455         8.739217000 seconds sys
456
457TIMINGS
458-------
459As displayed in the example above we can display 3 types of timings.
460We always display the time the counters were enabled/alive:
461
462        83.409183620 seconds time elapsed
463
464For workload sessions we also display time the workloads spent in
465user/system lands:
466
467        74.684747000 seconds user
468         8.739217000 seconds sys
469
470Those times are the very same as displayed by the 'time' tool.
471
472CSV FORMAT
473----------
474
475With -x, perf stat is able to output a not-quite-CSV format output
476Commas in the output are not put into "". To make it easy to parse
477it is recommended to use a different character like -x \;
478
479The fields are in this order:
480
481	- optional usec time stamp in fractions of second (with -I xxx)
482	- optional CPU, core, or socket identifier
483	- optional number of logical CPUs aggregated
484	- counter value
485	- unit of the counter value or empty
486	- event name
487	- run time of counter
488	- percentage of measurement time the counter was running
489	- optional variance if multiple values are collected with -r
490	- optional metric value
491	- optional unit of metric
492
493Additional metrics may be printed with all earlier fields being empty.
494
495SEE ALSO
496--------
497linkperf:perf-top[1], linkperf:perf-list[1]
498