xref: /linux/tools/perf/Documentation/perf-record.txt (revision b61104e7a6349bd2c2b3e2fb3260d87f15eda8f4)
1perf-record(1)
2==============
3
4NAME
5----
6perf-record - Run a command and record its profile into perf.data
7
8SYNOPSIS
9--------
10[verse]
11'perf record' [-e <EVENT> | --event=EVENT] [-a] <command>
12'perf record' [-e <EVENT> | --event=EVENT] [-a] \-- <command> [<options>]
13
14DESCRIPTION
15-----------
16This command runs a command and gathers a performance counter profile
17from it, into perf.data - without displaying anything.
18
19This file can then be inspected later on, using 'perf report'.
20
21
22OPTIONS
23-------
24<command>...::
25	Any command you can specify in a shell.
26
27-e::
28--event=::
29	Select the PMU event. Selection can be:
30
31        - a symbolic event name	(use 'perf list' to list all events)
32
33        - a raw PMU event in the form of rN where N is a hexadecimal value
34          that represents the raw register encoding with the layout of the
35          event control registers as described by entries in
36          /sys/bus/event_source/devices/cpu/format/*.
37
38        - a symbolic or raw PMU event followed by an optional colon
39	  and a list of event modifiers, e.g., cpu-cycles:p.  See the
40	  linkperf:perf-list[1] man page for details on event modifiers.
41
42	- a symbolically formed PMU event like 'pmu/param1=0x3,param2/' where
43	  'param1', 'param2', etc are defined as formats for the PMU in
44	  /sys/bus/event_source/devices/<pmu>/format/*.
45
46	- a symbolically formed event like 'pmu/config=M,config1=N,config3=K/'
47
48          where M, N, K are numbers (in decimal, hex, octal format). Acceptable
49          values for each of 'config', 'config1' and 'config2' are defined by
50          corresponding entries in /sys/bus/event_source/devices/<pmu>/format/*
51          param1 and param2 are defined as formats for the PMU in:
52          /sys/bus/event_source/devices/<pmu>/format/*
53
54	  There are also some parameters which are not defined in .../<pmu>/format/*.
55	  These params can be used to overload default config values per event.
56	  Here are some common parameters:
57	  - 'period': Set event sampling period
58	  - 'freq': Set event sampling frequency
59	  - 'time': Disable/enable time stamping. Acceptable values are 1 for
60		    enabling time stamping. 0 for disabling time stamping.
61		    The default is 1.
62	  - 'call-graph': Disable/enable callgraph. Acceptable str are "fp" for
63			 FP mode, "dwarf" for DWARF mode, "lbr" for LBR mode and
64			 "no" for disable callgraph.
65	  - 'stack-size': user stack size for dwarf mode
66	  - 'name' : User defined event name. Single quotes (') may be used to
67		    escape symbols in the name from parsing by shell and tool
68		    like this: name=\'CPU_CLK_UNHALTED.THREAD:cmask=0x1\'.
69	  - 'aux-output': Generate AUX records instead of events. This requires
70			  that an AUX area event is also provided.
71	  - 'aux-action': "pause" or "resume" to pause or resume an AUX
72			  area event (the group leader) when this event occurs.
73			  "start-paused" on an AUX area event itself, will
74			  start in a paused state.
75	  - 'aux-sample-size': Set sample size for AUX area sampling. If the
76	  '--aux-sample' option has been used, set aux-sample-size=0 to disable
77	  AUX area sampling for the event.
78
79          See the linkperf:perf-list[1] man page for more parameters.
80
81	  Note: If user explicitly sets options which conflict with the params,
82	  the value set by the parameters will be overridden.
83
84	  Also not defined in .../<pmu>/format/* are PMU driver specific
85	  configuration parameters.  Any configuration parameter preceded by
86	  the letter '@' is not interpreted in user space and sent down directly
87	  to the PMU driver.  For example:
88
89	  perf record -e some_event/@cfg1,@cfg2=config/ ...
90
91	  will see 'cfg1' and 'cfg2=config' pushed to the PMU driver associated
92	  with the event for further processing.  There is no restriction on
93	  what the configuration parameters are, as long as their semantic is
94	  understood and supported by the PMU driver.
95
96        - a hardware breakpoint event in the form of '\mem:addr[/len][:access]'
97          where addr is the address in memory you want to break in.
98          Access is the memory access type (read, write, execute) it can
99          be passed as follows: '\mem:addr[:[r][w][x]]'. len is the range,
100          number of bytes from specified addr, which the breakpoint will cover.
101          If you want to profile read-write accesses in 0x1000, just set
102          'mem:0x1000:rw'.
103          If you want to profile write accesses in [0x1000~1008), just set
104          'mem:0x1000/8:w'.
105
106	- a group of events surrounded by a pair of brace ("{event1,event2,...}").
107	  Each event is separated by commas and the group should be quoted to
108	  prevent the shell interpretation.  You also need to use --group on
109	  "perf report" to view group events together.
110
111--filter=<filter>::
112	Event filter.  This option should follow an event selector (-e).
113	If the event is a tracepoint, the filter string will be parsed by
114	the kernel.  If the event is a hardware trace PMU (e.g. Intel PT
115	or CoreSight), it'll be processed as an address filter.  Otherwise
116	it means a general filter using BPF which can be applied for any
117	kind of event.
118
119	- tracepoint filters
120
121	In the case of tracepoints, multiple '--filter' options are combined
122	using '&&'.
123
124	- address filters
125
126	A hardware trace PMU advertises its ability to accept a number of
127	address filters	by specifying a non-zero value in
128	/sys/bus/event_source/devices/<pmu>/nr_addr_filters.
129
130	Address filters have the format:
131
132	filter|start|stop|tracestop <start> [/ <size>] [@<file name>]
133
134	Where:
135	- 'filter': defines a region that will be traced.
136	- 'start': defines an address at which tracing will begin.
137	- 'stop': defines an address at which tracing will stop.
138	- 'tracestop': defines a region in which tracing will stop.
139
140	<file name> is the name of the object file, <start> is the offset to the
141	code to trace in that file, and <size> is the size of the region to
142	trace. 'start' and 'stop' filters need not specify a <size>.
143
144	If no object file is specified then the kernel is assumed, in which case
145	the start address must be a current kernel memory address.
146
147	<start> can also be specified by providing the name of a symbol. If the
148	symbol name is not unique, it can be disambiguated by inserting #n where
149	'n' selects the n'th symbol in address order. Alternately #0, #g or #G
150	select only a global symbol. <size> can also be specified by providing
151	the name of a symbol, in which case the size is calculated to the end
152	of that symbol. For 'filter' and 'tracestop' filters, if <size> is
153	omitted and <start> is a symbol, then the size is calculated to the end
154	of that symbol.
155
156	If <size> is omitted and <start> is '*', then the start and size will
157	be calculated from the first and last symbols, i.e. to trace the whole
158	file.
159
160	If symbol names (or '*') are provided, they must be surrounded by white
161	space.
162
163	The filter passed to the kernel is not necessarily the same as entered.
164	To see the filter that is passed, use the -v option.
165
166	The kernel may not be able to configure a trace region if it is not
167	within a single mapping.  MMAP events (or /proc/<pid>/maps) can be
168	examined to determine if that is a possibility.
169
170	Multiple filters can be separated with space or comma.
171
172	- bpf filters
173
174	A BPF filter can access the sample data and make a decision based on the
175	data.  Users need to set an appropriate sample type to use the BPF
176	filter.  BPF filters need root privilege.
177
178	The sample data field can be specified in lower case letter.  Multiple
179	filters can be separated with comma.  For example,
180
181	  --filter 'period > 1000, cpu == 1'
182	or
183	  --filter 'mem_op == load || mem_op == store, mem_lvl > l1'
184
185	The former filter only accept samples with period greater than 1000 AND
186	CPU number is 1.  The latter one accepts either load and store memory
187	operations but it should have memory level above the L1.  Since the
188	mem_op and mem_lvl fields come from the (memory) data_source, it'd only
189	work with some events which set the data_source field.
190
191	Also user should request to collect that information (with -d option in
192	the above case).  Otherwise, the following message will be shown.
193
194	  $ sudo perf record -e cycles --filter 'mem_op == load'
195	  Error: cycles event does not have PERF_SAMPLE_DATA_SRC
196	   Hint: please add -d option to perf record.
197	  failed to set filter "BPF" on event cycles with 22 (Invalid argument)
198
199	Essentially the BPF filter expression is:
200
201	  <term> <operator> <value> (("," | "||") <term> <operator> <value>)*
202
203	The <term> can be one of:
204	  ip, id, tid, pid, cpu, time, addr, period, txn, weight, phys_addr,
205	  code_pgsz, data_pgsz, weight1, weight2, weight3, ins_lat, retire_lat,
206	  p_stage_cyc, mem_op, mem_lvl, mem_snoop, mem_remote, mem_lock,
207	  mem_dtlb, mem_blk, mem_hops, uid, gid
208
209	The <operator> can be one of:
210	  ==, !=, >, >=, <, <=, &
211
212	The <value> can be one of:
213	  <number> (for any term)
214	  na, load, store, pfetch, exec (for mem_op)
215	  l1, l2, l3, l4, cxl, io, any_cache, lfb, ram, pmem (for mem_lvl)
216	  na, none, hit, miss, hitm, fwd, peer (for mem_snoop)
217	  remote (for mem_remote)
218	  na, locked (for mem_locked)
219	  na, l1_hit, l1_miss, l2_hit, l2_miss, any_hit, any_miss, walk, fault (for mem_dtlb)
220	  na, by_data, by_addr (for mem_blk)
221	  hops0, hops1, hops2, hops3 (for mem_hops)
222
223--exclude-perf::
224	Don't record events issued by perf itself. This option should follow
225	an event selector (-e) which selects tracepoint event(s). It adds a
226	filter expression 'common_pid != $PERFPID' to filters. If other
227	'--filter' exists, the new filter expression will be combined with
228	them by '&&'.
229
230--latency::
231	Enable data collection for latency profiling.
232	Use perf report --latency for latency-centric profile.
233
234-a::
235--all-cpus::
236        System-wide collection from all CPUs (default if no target is specified).
237
238-p::
239--pid=::
240	Record events on existing process ID (comma separated list).
241
242-t::
243--tid=::
244        Record events on existing thread ID (comma separated list).
245        This option also disables inheritance by default.  Enable it by adding
246        --inherit.
247
248-u::
249--uid=::
250        Record events in threads owned by uid. Name or number.
251
252-r::
253--realtime=::
254	Collect data with this RT SCHED_FIFO priority.
255
256--no-buffering::
257	Collect data without buffering.
258
259-c::
260--count=::
261	Event period to sample.
262
263-o::
264--output=::
265	Output file name.
266
267-i::
268--no-inherit::
269	Child tasks do not inherit counters.
270
271-F::
272--freq=::
273	Profile at this frequency. Use 'max' to use the currently maximum
274	allowed frequency, i.e. the value in the kernel.perf_event_max_sample_rate
275	sysctl. Will throttle down to the currently maximum allowed frequency.
276	See --strict-freq.
277
278--strict-freq::
279	Fail if the specified frequency can't be used.
280
281-m::
282--mmap-pages=::
283	Number of mmap data pages (must be a power of two) or size
284	specification in bytes with appended unit character - B/K/M/G.
285	The size is rounded up to the nearest power-of-two page value.
286	By adding a comma, an additional parameter with the same
287	semantics used for the normal mmap areas can be specified for
288	AUX tracing area.
289
290-g::
291	Enables call-graph (stack chain/backtrace) recording for both
292	kernel space and user space.
293
294--call-graph::
295	Setup and enable call-graph (stack chain/backtrace) recording,
296	implies -g.  Default is "fp" (for user space).
297
298	The unwinding method used for kernel space is dependent on the
299	unwinder used by the active kernel configuration, i.e
300	CONFIG_UNWINDER_FRAME_POINTER (fp) or CONFIG_UNWINDER_ORC (orc)
301
302	Any option specified here controls the method used for user space.
303
304	Valid options are "fp" (frame pointer), "dwarf" (DWARF's CFI -
305	Call Frame Information) or "lbr" (Hardware Last Branch Record
306	facility).
307
308	In some systems, where binaries are build with gcc
309	--fomit-frame-pointer, using the "fp" method will produce bogus
310	call graphs, using "dwarf", if available (perf tools linked to
311	the libunwind or libdw library) should be used instead.
312	Using the "lbr" method doesn't require any compiler options. It
313	will produce call graphs from the hardware LBR registers. The
314	main limitation is that it is only available on new Intel
315	platforms, such as Haswell. It can only get user call chain. It
316	doesn't work with branch stack sampling at the same time.
317
318	When "dwarf" recording is used, perf also records (user) stack dump
319	when sampled.  Default size of the stack dump is 8192 (bytes).
320	User can change the size by passing the size after comma like
321	"--call-graph dwarf,4096".
322
323	When "fp" recording is used, perf tries to save stack entries
324	up to the number specified in sysctl.kernel.perf_event_max_stack
325	by default.  User can change the number by passing it after comma
326	like "--call-graph fp,32".
327
328	Also "defer" can be used with "fp" (like "--call-graph fp,defer") to
329	enable deferred user callchain which will collect user-space callchains
330	when the thread returns to the user space.
331
332-q::
333--quiet::
334	Don't print any warnings or messages, useful for scripting.
335
336-v::
337--verbose::
338	Be more verbose (show counter open errors, etc).
339
340-s::
341--stat::
342	Record per-thread event counts.  Use it with 'perf report -T' to see
343	the values.
344
345-d::
346--data::
347	Record the sample virtual addresses.  Implies --sample-mem-info.
348
349--phys-data::
350	Record the sample physical addresses.
351
352--data-page-size::
353	Record the sampled data address data page size.
354
355--code-page-size::
356	Record the sampled code address (ip) page size
357
358-T::
359--timestamp::
360	Record the sample timestamps. Use it with 'perf report -D' to see the
361	timestamps, for instance.
362
363-P::
364--period::
365	Record the sample period.
366
367--sample-cpu::
368	Record the sample cpu.
369
370--sample-identifier::
371	Record the sample identifier i.e. PERF_SAMPLE_IDENTIFIER bit set in
372	the sample_type member of the struct perf_event_attr argument to the
373	perf_event_open system call.
374
375--sample-mem-info::
376	Record the sample data source information for memory operations.
377	It requires hardware supports and may work on specific events only.
378	Please consider using 'perf mem record' instead if you're not sure.
379
380-n::
381--no-samples::
382	Don't sample.
383
384-R::
385--raw-samples::
386Collect raw sample records from all opened counters (default for tracepoint counters).
387
388-C::
389--cpu::
390Collect samples only on the list of CPUs provided. Multiple CPUs can be provided as a
391comma-separated list with no space: 0,1. Ranges of CPUs are specified with -: 0-2.
392In per-thread mode with inheritance mode on (default), samples are captured only when
393the thread executes on the designated CPUs. Default is to monitor all CPUs.
394
395User space tasks can migrate between CPUs, so when tracing selected CPUs,
396a dummy event is created to track sideband for all CPUs.
397
398-B::
399--no-buildid::
400Do not save the build ids of binaries in the perf.data files. This skips
401post processing after recording, which sometimes makes the final step in
402the recording process to take a long time, as it needs to process all
403events looking for mmap records. The downside is that it can misresolve
404symbols if the workload binaries used when recording get locally rebuilt
405or upgraded, because the only key available in this case is the
406pathname. You can also set the "record.build-id" config variable to
407'skip to have this behaviour permanently.
408
409-N::
410--no-buildid-cache::
411Do not update the buildid cache. This saves some overhead in situations
412where the information in the perf.data file (which includes buildids)
413is sufficient.  You can also set the "record.build-id" config variable to
414'no-cache' to have the same effect.
415
416-G name,...::
417--cgroup name,...::
418monitor only in the container (cgroup) called "name". This option is available only
419in per-cpu mode. The cgroup filesystem must be mounted. All threads belonging to
420container "name" are monitored when they run on the monitored CPUs. Multiple cgroups
421can be provided. Each cgroup is applied to the corresponding event, i.e., first cgroup
422to first event, second cgroup to second event and so on. It is possible to provide
423an empty cgroup (monitor all the time) using, e.g., -G foo,,bar. Cgroups must have
424corresponding events, i.e., they always refer to events defined earlier on the command
425line. If the user wants to track multiple events for a specific cgroup, the user can
426use '-e e1 -e e2 -G foo,foo' or just use '-e e1 -e e2 -G foo'.
427
428If wanting to monitor, say, 'cycles' for a cgroup and also for system wide, this
429command line can be used: 'perf stat -e cycles -G cgroup_name -a -e cycles'.
430
431-b::
432--branch-any::
433Enable taken branch stack sampling. Any type of taken branch may be sampled.
434This is a shortcut for --branch-filter any. See --branch-filter for more infos.
435
436-j::
437--branch-filter::
438Enable taken branch stack sampling. Each sample captures a series of consecutive
439taken branches. The number of branches captured with each sample depends on the
440underlying hardware, the type of branches of interest, and the executed code.
441It is possible to select the types of branches captured by enabling filters. The
442following filters are defined:
443
444        - any:  any type of branches
445        - any_call: any function call or system call
446        - any_ret: any function return or system call return
447        - ind_call: any indirect branch
448        - ind_jmp: any indirect jump
449        - call: direct calls, including far (to/from kernel) calls
450        - u:  only when the branch target is at the user level
451        - k: only when the branch target is in the kernel
452        - hv: only when the target is at the hypervisor level
453	- in_tx: only when the target is in a hardware transaction
454	- no_tx: only when the target is not in a hardware transaction
455	- abort_tx: only when the target is a hardware transaction abort
456	- cond: conditional branches
457	- call_stack: save call stack
458	- no_flags: don't save branch flags e.g prediction, misprediction etc
459	- no_cycles: don't save branch cycles
460	- hw_index: save branch hardware index
461	- save_type: save branch type during sampling in case binary is not available later
462		     For the platforms with Intel Arch LBR support (12th-Gen+ client or
463		     4th-Gen Xeon+ server), the save branch type is unconditionally enabled
464		     when the taken branch stack sampling is enabled.
465	- priv: save privilege state during sampling in case binary is not available later
466	- counter: save occurrences of the event since the last branch entry. Currently, the
467		   feature is only supported by a newer CPU, e.g., Intel Sierra Forest and
468		   later platforms. An error out is expected if it's used on the unsupported
469		   kernel or CPUs.
470
471+
472The option requires at least one branch type among any, any_call, any_ret, ind_call, cond.
473The privilege levels may be omitted, in which case, the privilege levels of the associated
474event are applied to the branch filter. Both kernel (k) and hypervisor (hv) privilege
475levels are subject to permissions.  When sampling on multiple events, branch stack sampling
476is enabled for all the sampling events. The sampled branch type is the same for all events.
477The various filters must be specified as a comma separated list: --branch-filter any_ret,u,k
478Note that this feature may not be available on all processors.
479
480-W::
481--weight::
482Enable weightened sampling. An additional weight is recorded per sample and can be
483displayed with the weight and local_weight sort keys.  This currently works for TSX
484abort events and some memory events in precise mode on modern Intel CPUs.
485
486--namespaces::
487Record events of type PERF_RECORD_NAMESPACES.  This enables 'cgroup_id' sort key.
488
489--all-cgroups::
490Record events of type PERF_RECORD_CGROUP.  This enables 'cgroup' sort key.
491
492--transaction::
493Record transaction flags for transaction related events.
494
495--per-thread::
496Use per-thread mmaps.  By default per-cpu mmaps are created.  This option
497overrides that and uses per-thread mmaps.  A side-effect of that is that
498inheritance is automatically disabled.  --per-thread is ignored with a warning
499if combined with -a or -C options.
500
501-D::
502--delay=::
503After starting the program, wait msecs before measuring (-1: start with events
504disabled), or enable events only for specified ranges of msecs (e.g.
505-D 10-20,30-40 means wait 10 msecs, enable for 10 msecs, wait 10 msecs, enable
506for 10 msecs, then stop). Note, delaying enabling of events is useful to filter
507out the startup phase of the program, which is often very different.
508
509-I::
510--intr-regs::
511Capture machine state (registers) at interrupt, i.e., on counter overflows for
512each sample. List of captured registers depends on the architecture. This option
513is off by default. It is possible to select the registers to sample using their
514symbolic names, e.g. on x86, ax, si. To list the available registers use
515--intr-regs=\?. To name registers, pass a comma separated list such as
516--intr-regs=ax,bx. The list of register is architecture dependent.
517
518--user-regs::
519Similar to -I, but capture user registers at sample time. To list the available
520user registers use --user-regs=\?.
521
522--running-time::
523Record running and enabled time for read events (:S)
524
525-k::
526--clockid::
527Sets the clock id to use for the various time fields in the perf_event_type
528records. See clock_gettime(). In particular CLOCK_MONOTONIC and
529CLOCK_MONOTONIC_RAW are supported, some events might also allow
530CLOCK_BOOTTIME, CLOCK_REALTIME and CLOCK_TAI.
531
532-S::
533--snapshot::
534Select AUX area tracing Snapshot Mode. This option is valid only with an
535AUX area tracing event. Optionally, certain snapshot capturing parameters
536can be specified in a string that follows this option:
537
538  - 'e': take one last snapshot on exit; guarantees that there is at least one
539       snapshot in the output file;
540  - <size>: if the PMU supports this, specify the desired snapshot size.
541
542In Snapshot Mode trace data is captured only when signal SIGUSR2 is received
543and on exit if the above 'e' option is given.
544
545--aux-sample[=OPTIONS]::
546Select AUX area sampling. At least one of the events selected by the -e option
547must be an AUX area event. Samples on other events will be created containing
548data from the AUX area. Optionally sample size may be specified, otherwise it
549defaults to 4KiB.
550
551--proc-map-timeout::
552When processing pre-existing threads /proc/XXX/mmap, it may take a long time,
553because the file may be huge. A time out is needed in such cases.
554This option sets the time out limit. The default value is 500 ms.
555
556--switch-events::
557Record context switch events i.e. events of type PERF_RECORD_SWITCH or
558PERF_RECORD_SWITCH_CPU_WIDE. In some cases (e.g. Intel PT, CoreSight or Arm SPE)
559switch events will be enabled automatically, which can be suppressed by
560by the option --no-switch-events.
561
562--vmlinux=PATH::
563Specify vmlinux path which has debuginfo.
564(enabled when BPF prologue is on)
565
566--buildid-all::
567Record build-id of all DSOs regardless whether it's actually hit or not.
568
569--buildid-mmap::
570Legacy record build-id in map events option which is now the
571default. Behaves indentically to --no-buildid. Disable with
572--no-buildid-mmap.
573
574--aio[=n]::
575Use <n> control blocks in asynchronous (Posix AIO) trace writing mode (default: 1, max: 4).
576Asynchronous mode is supported only when linking Perf tool with libc library
577providing implementation for Posix AIO API.
578
579--affinity=mode::
580Set affinity mask of trace reading thread according to the policy defined by 'mode' value:
581
582  - node - thread affinity mask is set to NUMA node cpu mask of the processed mmap buffer
583  - cpu  - thread affinity mask is set to cpu of the processed mmap buffer
584
585--mmap-flush=number::
586
587Specify minimal number of bytes that is extracted from mmap data pages and
588processed for output. One can specify the number using B/K/M/G suffixes.
589
590The maximal allowed value is a quarter of the size of mmaped data pages.
591
592The default option value is 1 byte which means that every time that the output
593writing thread finds some new data in the mmaped buffer the data is extracted,
594possibly compressed (-z) and written to the output, perf.data or pipe.
595
596Larger data chunks are compressed more effectively in comparison to smaller
597chunks so extraction of larger chunks from the mmap data pages is preferable
598from the perspective of output size reduction.
599
600Also at some cases executing less output write syscalls with bigger data size
601can take less time than executing more output write syscalls with smaller data
602size thus lowering runtime profiling overhead.
603
604-z::
605--compression-level[=n]::
606Produce compressed trace using specified level n (default: 1 - fastest compression,
60722 - smallest trace)
608
609--all-kernel::
610Configure all used events to run in kernel space.
611
612--all-user::
613Configure all used events to run in user space.
614
615--kernel-callchains::
616Collect callchains only from kernel space. I.e. this option sets
617perf_event_attr.exclude_callchain_user to 1.
618
619--user-callchains::
620Collect callchains only from user space. I.e. this option sets
621perf_event_attr.exclude_callchain_kernel to 1.
622
623Don't use both --kernel-callchains and --user-callchains at the same time or no
624callchains will be collected.
625
626--timestamp-filename
627Append timestamp to output file name.
628
629--timestamp-boundary::
630Record timestamp boundary (time of first/last samples).
631
632--switch-output[=mode]::
633Generate multiple perf.data files, timestamp prefixed, switching to a new one
634based on 'mode' value:
635
636  - "signal" - when receiving a SIGUSR2 (default value) or
637  - <size>   - when reaching the size threshold, size is expected to
638               be a number with appended unit character - B/K/M/G
639  - <time>   - when reaching the time threshold, size is expected to
640               be a number with appended unit character - s/m/h/d
641
642               Note: the precision of  the size  threshold  hugely depends
643               on your configuration  - the number and size of  your  ring
644               buffers (-m). It is generally more precise for higher sizes
645               (like >5M), for lower values expect different sizes.
646
647A possible use case is to, given an external event, slice the perf.data file
648that gets then processed, possibly via a perf script, to decide if that
649particular perf.data snapshot should be kept or not.
650
651Implies --timestamp-filename, --no-buildid and --no-buildid-cache.
652The reason for the latter two is to reduce the data file switching
653overhead. You can still switch them on with:
654
655  --switch-output --no-no-buildid  --no-no-buildid-cache
656
657--switch-output-event::
658Events that will cause the switch of the perf.data file, auto-selecting
659--switch-output=signal, the results are similar as internally the side band
660thread will also send a SIGUSR2 to the main one.
661
662Uses the same syntax as --event, it will just not be recorded, serving only to
663switch the perf.data file as soon as the --switch-output event is processed by
664a separate sideband thread.
665
666This sideband thread is also used to other purposes, like processing the
667PERF_RECORD_BPF_EVENT records as they happen, asking the kernel for extra BPF
668information, etc.
669
670--switch-max-files=N::
671
672When rotating perf.data with --switch-output, only keep N files.
673
674--dry-run::
675Parse options then exit. --dry-run can be used to detect errors in cmdline
676options.
677
678'perf record --dry-run -e' can act as a BPF script compiler if llvm.dump-obj
679in config file is set to true.
680
681--synth=TYPE::
682Collect and synthesize given type of events (comma separated).  Note that
683this option controls the synthesis from the /proc filesystem which represent
684task status for pre-existing threads.
685
686Kernel (and some other) events are recorded regardless of the
687choice in this option.  For example, --synth=no would have MMAP events for
688kernel and modules.
689
690Available types are:
691
692  - 'task'    - synthesize FORK and COMM events for each task
693  - 'mmap'    - synthesize MMAP events for each process (implies 'task')
694  - 'cgroup'  - synthesize CGROUP events for each cgroup
695  - 'all'     - synthesize all events (default)
696  - 'no'      - do not synthesize any of the above events
697
698--tail-synthesize::
699Instead of collecting non-sample events (for example, fork, comm, mmap) at
700the beginning of record, collect them during finalizing an output file.
701The collected non-sample events reflects the status of the system when
702record is finished.
703
704--overwrite::
705Makes all events use an overwritable ring buffer. An overwritable ring
706buffer works like a flight recorder: when it gets full, the kernel will
707overwrite the oldest records, that thus will never make it to the
708perf.data file.
709
710When '--overwrite' and '--switch-output' are used perf records and drops
711events until it receives a signal, meaning that something unusual was
712detected that warrants taking a snapshot of the most current events,
713those fitting in the ring buffer at that moment.
714
715'overwrite' attribute can also be set or canceled for an event using
716config terms. For example: 'cycles/overwrite/' and 'instructions/no-overwrite/'.
717
718Implies --tail-synthesize.
719
720--kcore::
721Make a copy of /proc/kcore and place it into a directory with the perf data file.
722
723--max-size=<size>::
724Limit the sample data max size, <size> is expected to be a number with
725appended unit character - B/K/M/G
726
727--num-thread-synthesize::
728	The number of threads to run when synthesizing events for existing processes.
729	By default, the number of threads equals 1.
730
731ifdef::HAVE_LIBPFM[]
732--pfm-events events::
733Select a PMU event using libpfm4 syntax (see http://perfmon2.sf.net)
734including support for event filters. For example '--pfm-events
735inst_retired:any_p:u:c=1:i'. More than one event can be passed to the
736option using the comma separator. Hardware events and generic hardware
737events cannot be mixed together. The latter must be used with the -e
738option. The -e option and this one can be mixed and matched.  Events
739can be grouped using the {} notation.
740endif::HAVE_LIBPFM[]
741
742--control=fifo:ctl-fifo[,ack-fifo]::
743--control=fd:ctl-fd[,ack-fd]::
744ctl-fifo / ack-fifo are opened and used as ctl-fd / ack-fd as follows.
745Listen on ctl-fd descriptor for command to control measurement.
746
747Available commands:
748
749  - 'enable'           : enable events
750  - 'disable'          : disable events
751  - 'enable name'      : enable event 'name'
752  - 'disable name'     : disable event 'name'
753  - 'snapshot'         : AUX area tracing snapshot).
754  - 'stop'             : stop perf record
755  - 'ping'             : ping
756  - 'evlist [-v|-g|-F] : display all events
757
758                         -F  Show just the sample frequency used for each event.
759                         -v  Show all fields.
760                         -g  Show event group information.
761
762Measurements can be started with events disabled using --delay=-1 option. Optionally
763send control command completion ('ack\n') to ack-fd descriptor to synchronize with the
764controlling process.  Example of bash shell script to enable and disable events during
765measurements:
766
767 #!/bin/bash
768
769 ctl_dir=/tmp/
770
771 ctl_fifo=${ctl_dir}perf_ctl.fifo
772 test -p ${ctl_fifo} && unlink ${ctl_fifo}
773 mkfifo ${ctl_fifo}
774 exec {ctl_fd}<>${ctl_fifo}
775
776 ctl_ack_fifo=${ctl_dir}perf_ctl_ack.fifo
777 test -p ${ctl_ack_fifo} && unlink ${ctl_ack_fifo}
778 mkfifo ${ctl_ack_fifo}
779 exec {ctl_fd_ack}<>${ctl_ack_fifo}
780
781 perf record -D -1 -e cpu-cycles -a               \
782             --control fd:${ctl_fd},${ctl_fd_ack} \
783             -- sleep 30 &
784 perf_pid=$!
785
786 sleep 5  && echo 'enable' >&${ctl_fd} && read -u ${ctl_fd_ack} e1 && echo "enabled(${e1})"
787 sleep 10 && echo 'disable' >&${ctl_fd} && read -u ${ctl_fd_ack} d1 && echo "disabled(${d1})"
788
789 exec {ctl_fd_ack}>&-
790 unlink ${ctl_ack_fifo}
791
792 exec {ctl_fd}>&-
793 unlink ${ctl_fifo}
794
795 wait -n ${perf_pid}
796 exit $?
797
798--threads=<spec>::
799Write collected trace data into several data files using parallel threads.
800<spec> value can be user defined list of masks. Masks separated by colon
801define CPUs to be monitored by a thread and affinity mask of that thread
802is separated by slash:
803
804    <cpus mask 1>/<affinity mask 1>:<cpus mask 2>/<affinity mask 2>:...
805
806CPUs or affinity masks must not overlap with other corresponding masks.
807Invalid CPUs are ignored, but masks containing only invalid CPUs are not
808allowed.
809
810For example user specification like the following:
811
812    0,2-4/2-4:1,5-7/5-7
813
814specifies parallel threads layout that consists of two threads,
815the first thread monitors CPUs 0 and 2-4 with the affinity mask 2-4,
816the second monitors CPUs 1 and 5-7 with the affinity mask 5-7.
817
818<spec> value can also be a string meaning predefined parallel threads
819layout:
820
821    - cpu    - create new data streaming thread for every monitored cpu
822    - core   - create new thread to monitor CPUs grouped by a core
823    - package - create new thread to monitor CPUs grouped by a package
824    - numa   - create new threed to monitor CPUs grouped by a NUMA domain
825
826Predefined layouts can be used on systems with large number of CPUs in
827order not to spawn multiple per-cpu streaming threads but still avoid LOST
828events in data directory files. Option specified with no or empty value
829defaults to CPU layout. Masks defined or provided by the option value are
830filtered through the mask provided by -C option.
831
832--debuginfod[=URLs]::
833	Specify debuginfod URL to be used when cacheing perf.data binaries,
834	it follows the same syntax as the DEBUGINFOD_URLS variable, like:
835
836	  http://192.168.122.174:8002
837
838	If the URLs is not specified, the value of DEBUGINFOD_URLS
839	system environment variable is used.
840
841--off-cpu::
842	Enable off-cpu profiling with BPF.  The BPF program will collect
843	task scheduling information with (user) stacktrace and save them
844	as sample data of a software event named "offcpu-time".  The
845	sample period will have the time the task slept in nanoseconds.
846
847	Note that BPF can collect stack traces using frame pointer ("fp")
848	only, as of now.  So the applications built without the frame
849	pointer might see bogus addresses.
850
851	off-cpu profiling consists two types of samples: direct samples, which
852	share the same behavior as regular samples, and the accumulated
853	samples, stored in BPF stack trace map, presented after all the regular
854	samples.
855
856--off-cpu-thresh::
857	Once a task's off-cpu time reaches this threshold (in milliseconds), it
858	generates a direct off-cpu sample. The default is 500ms.
859
860--setup-filter=<action>::
861	Prepare BPF filter to be used by regular users.  The action should be
862	either "pin" or "unpin".  The filter can be used after it's pinned.
863
864
865include::intel-hybrid.txt[]
866
867SEE ALSO
868--------
869linkperf:perf-stat[1], linkperf:perf-list[1], linkperf:perf-intel-pt[1]
870