1perf-intel-pt(1)
2================
3
4NAME
5----
6perf-intel-pt - Support for Intel Processor Trace within perf tools
7
8SYNOPSIS
9--------
10[verse]
11'perf record' -e intel_pt//
12
13DESCRIPTION
14-----------
15
16Intel Processor Trace (Intel PT) is an extension of Intel Architecture that
17collects information about software execution such as control flow, execution
18modes and timings and formats it into highly compressed binary packets.
19Technical details are documented in the Intel 64 and IA-32 Architectures
20Software Developer Manuals, Chapter 36 Intel Processor Trace.
21
22Intel PT is first supported in Intel Core M and 5th generation Intel Core
23processors that are based on the Intel micro-architecture code name Broadwell.
24
25Trace data is collected by 'perf record' and stored within the perf.data file.
26See below for options to 'perf record'.
27
28Trace data must be 'decoded' which involves walking the object code and matching
29the trace data packets. For example a TNT packet only tells whether a
30conditional branch was taken or not taken, so to make use of that packet the
31decoder must know precisely which instruction was being executed.
32
33Decoding is done on-the-fly.  The decoder outputs samples in the same format as
34samples output by perf hardware events, for example as though the "instructions"
35or "branches" events had been recorded.  Presently 3 tools support this:
36'perf script', 'perf report' and 'perf inject'.  See below for more information
37on using those tools.
38
39The main distinguishing feature of Intel PT is that the decoder can determine
40the exact flow of software execution.  Intel PT can be used to understand why
41and how did software get to a certain point, or behave a certain way.  The
42software does not have to be recompiled, so Intel PT works with debug or release
43builds, however the executed images are needed - which makes use in JIT-compiled
44environments, or with self-modified code, a challenge.  Also symbols need to be
45provided to make sense of addresses.
46
47A limitation of Intel PT is that it produces huge amounts of trace data
48(hundreds of megabytes per second per core) which takes a long time to decode,
49for example two or three orders of magnitude longer than it took to collect.
50Another limitation is the performance impact of tracing, something that will
51vary depending on the use-case and architecture.
52
53
54Quickstart
55----------
56
57It is important to start small.  That is because it is easy to capture vastly
58more data than can possibly be processed.
59
60The simplest thing to do with Intel PT is userspace profiling of small programs.
61Data is captured with 'perf record' e.g. to trace 'ls' userspace-only:
62
63	perf record -e intel_pt//u ls
64
65And profiled with 'perf report' e.g.
66
67	perf report
68
69To also trace kernel space presents a problem, namely kernel self-modifying
70code.  A fairly good kernel image is available in /proc/kcore but to get an
71accurate image a copy of /proc/kcore needs to be made under the same conditions
72as the data capture.  A script perf-with-kcore can do that, but beware that the
73script makes use of 'sudo' to copy /proc/kcore.  If you have perf installed
74locally from the source tree you can do:
75
76	~/libexec/perf-core/perf-with-kcore record pt_ls -e intel_pt// -- ls
77
78which will create a directory named 'pt_ls' and put the perf.data file and
79copies of /proc/kcore, /proc/kallsyms and /proc/modules into it.  Then to use
80'perf report' becomes:
81
82	~/libexec/perf-core/perf-with-kcore report pt_ls
83
84Because samples are synthesized after-the-fact, the sampling period can be
85selected for reporting. e.g. sample every microsecond
86
87	~/libexec/perf-core/perf-with-kcore report pt_ls --itrace=i1usge
88
89See the sections below for more information about the --itrace option.
90
91Beware the smaller the period, the more samples that are produced, and the
92longer it takes to process them.
93
94Also note that the coarseness of Intel PT timing information will start to
95distort the statistical value of the sampling as the sampling period becomes
96smaller.
97
98To represent software control flow, "branches" samples are produced.  By default
99a branch sample is synthesized for every single branch.  To get an idea what
100data is available you can use the 'perf script' tool with all itrace sampling
101options, which will list all the samples.
102
103	perf record -e intel_pt//u ls
104	perf script --itrace=ibxwpe
105
106An interesting field that is not printed by default is 'flags' which can be
107displayed as follows:
108
109	perf script --itrace=ibxwpe -F+flags
110
111The flags are "bcrosyiABEx" which stand for branch, call, return, conditional,
112system, asynchronous, interrupt, transaction abort, trace begin, trace end, and
113in transaction, respectively.
114
115Another interesting field that is not printed by default is 'ipc' which can be
116displayed as follows:
117
118	perf script --itrace=be -F+ipc
119
120There are two ways that instructions-per-cycle (IPC) can be calculated depending
121on the recording.
122
123If the 'cyc' config term (see config terms section below) was used, then IPC is
124calculated using the cycle count from CYC packets, otherwise MTC packets are
125used - refer to the 'mtc' config term.  When MTC is used, however, the values
126are less accurate because the timing is less accurate.
127
128Because Intel PT does not update the cycle count on every branch or instruction,
129the values will often be zero.  When there are values, they will be the number
130of instructions and number of cycles since the last update, and thus represent
131the average IPC since the last IPC for that event type.  Note IPC for "branches"
132events is calculated separately from IPC for "instructions" events.
133
134Also note that the IPC instruction count may or may not include the current
135instruction.  If the cycle count is associated with an asynchronous branch
136(e.g. page fault or interrupt), then the instruction count does not include the
137current instruction, otherwise it does.  That is consistent with whether or not
138that instruction has retired when the cycle count is updated.
139
140Another note, in the case of "branches" events, non-taken branches are not
141presently sampled, so IPC values for them do not appear e.g. a CYC packet with a
142TNT packet that starts with a non-taken branch.  To see every possible IPC
143value, "instructions" events can be used e.g. --itrace=i0ns
144
145While it is possible to create scripts to analyze the data, an alternative
146approach is available to export the data to a sqlite or postgresql database.
147Refer to script export-to-sqlite.py or export-to-postgresql.py for more details,
148and to script exported-sql-viewer.py for an example of using the database.
149
150There is also script intel-pt-events.py which provides an example of how to
151unpack the raw data for power events and PTWRITE.
152
153As mentioned above, it is easy to capture too much data.  One way to limit the
154data captured is to use 'snapshot' mode which is explained further below.
155Refer to 'new snapshot option' and 'Intel PT modes of operation' further below.
156
157Another problem that will be experienced is decoder errors.  They can be caused
158by inability to access the executed image, self-modified or JIT-ed code, or the
159inability to match side-band information (such as context switches and mmaps)
160which results in the decoder not knowing what code was executed.
161
162There is also the problem of perf not being able to copy the data fast enough,
163resulting in data lost because the buffer was full.  See 'Buffer handling' below
164for more details.
165
166
167perf record
168-----------
169
170new event
171~~~~~~~~~
172
173The Intel PT kernel driver creates a new PMU for Intel PT.  PMU events are
174selected by providing the PMU name followed by the "config" separated by slashes.
175An enhancement has been made to allow default "config" e.g. the option
176
177	-e intel_pt//
178
179will use a default config value.  Currently that is the same as
180
181	-e intel_pt/tsc,noretcomp=0/
182
183which is the same as
184
185	-e intel_pt/tsc=1,noretcomp=0/
186
187Note there are now new config terms - see section 'config terms' further below.
188
189The config terms are listed in /sys/devices/intel_pt/format.  They are bit
190fields within the config member of the struct perf_event_attr which is
191passed to the kernel by the perf_event_open system call.  They correspond to bit
192fields in the IA32_RTIT_CTL MSR.  Here is a list of them and their definitions:
193
194	$ grep -H . /sys/bus/event_source/devices/intel_pt/format/*
195	/sys/bus/event_source/devices/intel_pt/format/cyc:config:1
196	/sys/bus/event_source/devices/intel_pt/format/cyc_thresh:config:19-22
197	/sys/bus/event_source/devices/intel_pt/format/mtc:config:9
198	/sys/bus/event_source/devices/intel_pt/format/mtc_period:config:14-17
199	/sys/bus/event_source/devices/intel_pt/format/noretcomp:config:11
200	/sys/bus/event_source/devices/intel_pt/format/psb_period:config:24-27
201	/sys/bus/event_source/devices/intel_pt/format/tsc:config:10
202
203Note that the default config must be overridden for each term i.e.
204
205	-e intel_pt/noretcomp=0/
206
207is the same as:
208
209	-e intel_pt/tsc=1,noretcomp=0/
210
211So, to disable TSC packets use:
212
213	-e intel_pt/tsc=0/
214
215It is also possible to specify the config value explicitly:
216
217	-e intel_pt/config=0x400/
218
219Note that, as with all events, the event is suffixed with event modifiers:
220
221	u	userspace
222	k	kernel
223	h	hypervisor
224	G	guest
225	H	host
226	p	precise ip
227
228'h', 'G' and 'H' are for virtualization which is not supported by Intel PT.
229'p' is also not relevant to Intel PT.  So only options 'u' and 'k' are
230meaningful for Intel PT.
231
232perf_event_attr is displayed if the -vv option is used e.g.
233
234	------------------------------------------------------------
235	perf_event_attr:
236	type                             6
237	size                             112
238	config                           0x400
239	{ sample_period, sample_freq }   1
240	sample_type                      IP|TID|TIME|CPU|IDENTIFIER
241	read_format                      ID
242	disabled                         1
243	inherit                          1
244	exclude_kernel                   1
245	exclude_hv                       1
246	enable_on_exec                   1
247	sample_id_all                    1
248	------------------------------------------------------------
249	sys_perf_event_open: pid 31104  cpu 0  group_fd -1  flags 0x8
250	sys_perf_event_open: pid 31104  cpu 1  group_fd -1  flags 0x8
251	sys_perf_event_open: pid 31104  cpu 2  group_fd -1  flags 0x8
252	sys_perf_event_open: pid 31104  cpu 3  group_fd -1  flags 0x8
253	------------------------------------------------------------
254
255
256config terms
257~~~~~~~~~~~~
258
259The June 2015 version of Intel 64 and IA-32 Architectures Software Developer
260Manuals, Chapter 36 Intel Processor Trace, defined new Intel PT features.
261Some of the features are reflect in new config terms.  All the config terms are
262described below.
263
264tsc		Always supported.  Produces TSC timestamp packets to provide
265		timing information.  In some cases it is possible to decode
266		without timing information, for example a per-thread context
267		that does not overlap executable memory maps.
268
269		The default config selects tsc (i.e. tsc=1).
270
271noretcomp	Always supported.  Disables "return compression" so a TIP packet
272		is produced when a function returns.  Causes more packets to be
273		produced but might make decoding more reliable.
274
275		The default config does not select noretcomp (i.e. noretcomp=0).
276
277psb_period	Allows the frequency of PSB packets to be specified.
278
279		The PSB packet is a synchronization packet that provides a
280		starting point for decoding or recovery from errors.
281
282		Support for psb_period is indicated by:
283
284			/sys/bus/event_source/devices/intel_pt/caps/psb_cyc
285
286		which contains "1" if the feature is supported and "0"
287		otherwise.
288
289		Valid values are given by:
290
291			/sys/bus/event_source/devices/intel_pt/caps/psb_periods
292
293		which contains a hexadecimal value, the bits of which represent
294		valid values e.g. bit 2 set means value 2 is valid.
295
296		The psb_period value is converted to the approximate number of
297		trace bytes between PSB packets as:
298
299			2 ^ (value + 11)
300
301		e.g. value 3 means 16KiB bytes between PSBs
302
303		If an invalid value is entered, the error message
304		will give a list of valid values e.g.
305
306			$ perf record -e intel_pt/psb_period=15/u uname
307			Invalid psb_period for intel_pt. Valid values are: 0-5
308
309		If MTC packets are selected, the default config selects a value
310		of 3 (i.e. psb_period=3) or the nearest lower value that is
311		supported (0 is always supported).  Otherwise the default is 0.
312
313		If decoding is expected to be reliable and the buffer is large
314		then a large PSB period can be used.
315
316		Because a TSC packet is produced with PSB, the PSB period can
317		also affect the granularity to timing information in the absence
318		of MTC or CYC.
319
320mtc		Produces MTC timing packets.
321
322		MTC packets provide finer grain timestamp information than TSC
323		packets.  MTC packets record time using the hardware crystal
324		clock (CTC) which is related to TSC packets using a TMA packet.
325
326		Support for this feature is indicated by:
327
328			/sys/bus/event_source/devices/intel_pt/caps/mtc
329
330		which contains "1" if the feature is supported and
331		"0" otherwise.
332
333		The frequency of MTC packets can also be specified - see
334		mtc_period below.
335
336mtc_period	Specifies how frequently MTC packets are produced - see mtc
337		above for how to determine if MTC packets are supported.
338
339		Valid values are given by:
340
341			/sys/bus/event_source/devices/intel_pt/caps/mtc_periods
342
343		which contains a hexadecimal value, the bits of which represent
344		valid values e.g. bit 2 set means value 2 is valid.
345
346		The mtc_period value is converted to the MTC frequency as:
347
348			CTC-frequency / (2 ^ value)
349
350		e.g. value 3 means one eighth of CTC-frequency
351
352		Where CTC is the hardware crystal clock, the frequency of which
353		can be related to TSC via values provided in cpuid leaf 0x15.
354
355		If an invalid value is entered, the error message
356		will give a list of valid values e.g.
357
358			$ perf record -e intel_pt/mtc_period=15/u uname
359			Invalid mtc_period for intel_pt. Valid values are: 0,3,6,9
360
361		The default value is 3 or the nearest lower value
362		that is supported (0 is always supported).
363
364cyc		Produces CYC timing packets.
365
366		CYC packets provide even finer grain timestamp information than
367		MTC and TSC packets.  A CYC packet contains the number of CPU
368		cycles since the last CYC packet. Unlike MTC and TSC packets,
369		CYC packets are only sent when another packet is also sent.
370
371		Support for this feature is indicated by:
372
373			/sys/bus/event_source/devices/intel_pt/caps/psb_cyc
374
375		which contains "1" if the feature is supported and
376		"0" otherwise.
377
378		The number of CYC packets produced can be reduced by specifying
379		a threshold - see cyc_thresh below.
380
381cyc_thresh	Specifies how frequently CYC packets are produced - see cyc
382		above for how to determine if CYC packets are supported.
383
384		Valid cyc_thresh values are given by:
385
386			/sys/bus/event_source/devices/intel_pt/caps/cycle_thresholds
387
388		which contains a hexadecimal value, the bits of which represent
389		valid values e.g. bit 2 set means value 2 is valid.
390
391		The cyc_thresh value represents the minimum number of CPU cycles
392		that must have passed before a CYC packet can be sent.  The
393		number of CPU cycles is:
394
395			2 ^ (value - 1)
396
397		e.g. value 4 means 8 CPU cycles must pass before a CYC packet
398		can be sent.  Note a CYC packet is still only sent when another
399		packet is sent, not at, e.g. every 8 CPU cycles.
400
401		If an invalid value is entered, the error message
402		will give a list of valid values e.g.
403
404			$ perf record -e intel_pt/cyc,cyc_thresh=15/u uname
405			Invalid cyc_thresh for intel_pt. Valid values are: 0-12
406
407		CYC packets are not requested by default.
408
409pt		Specifies pass-through which enables the 'branch' config term.
410
411		The default config selects 'pt' if it is available, so a user will
412		never need to specify this term.
413
414branch		Enable branch tracing.  Branch tracing is enabled by default so to
415		disable branch tracing use 'branch=0'.
416
417		The default config selects 'branch' if it is available.
418
419ptw		Enable PTWRITE packets which are produced when a ptwrite instruction
420		is executed.
421
422		Support for this feature is indicated by:
423
424			/sys/bus/event_source/devices/intel_pt/caps/ptwrite
425
426		which contains "1" if the feature is supported and
427		"0" otherwise.
428
429fup_on_ptw	Enable a FUP packet to follow the PTWRITE packet.  The FUP packet
430		provides the address of the ptwrite instruction.  In the absence of
431		fup_on_ptw, the decoder will use the address of the previous branch
432		if branch tracing is enabled, otherwise the address will be zero.
433		Note that fup_on_ptw will work even when branch tracing is disabled.
434
435pwr_evt		Enable power events.  The power events provide information about
436		changes to the CPU C-state.
437
438		Support for this feature is indicated by:
439
440			/sys/bus/event_source/devices/intel_pt/caps/power_event_trace
441
442		which contains "1" if the feature is supported and
443		"0" otherwise.
444
445
446AUX area sampling option
447~~~~~~~~~~~~~~~~~~~~~~~~
448
449To select Intel PT "sampling" the AUX area sampling option can be used:
450
451	--aux-sample
452
453Optionally it can be followed by the sample size in bytes e.g.
454
455	--aux-sample=8192
456
457In addition, the Intel PT event to sample must be defined e.g.
458
459	-e intel_pt//u
460
461Samples on other events will be created containing Intel PT data e.g. the
462following will create Intel PT samples on the branch-misses event, note the
463events must be grouped using {}:
464
465	perf record --aux-sample -e '{intel_pt//u,branch-misses:u}'
466
467An alternative to '--aux-sample' is to add the config term 'aux-sample-size' to
468events.  In this case, the grouping is implied e.g.
469
470	perf record -e intel_pt//u -e branch-misses/aux-sample-size=8192/u
471
472is the same as:
473
474	perf record -e '{intel_pt//u,branch-misses/aux-sample-size=8192/u}'
475
476but allows for also using an address filter e.g.:
477
478	perf record -e intel_pt//u --filter 'filter * @/bin/ls' -e branch-misses/aux-sample-size=8192/u -- ls
479
480It is important to select a sample size that is big enough to contain at least
481one PSB packet.  If not a warning will be displayed:
482
483	Intel PT sample size (%zu) may be too small for PSB period (%zu)
484
485The calculation used for that is: if sample_size <= psb_period + 256 display the
486warning.  When sampling is used, psb_period defaults to 0 (2KiB).
487
488The default sample size is 4KiB.
489
490The sample size is passed in aux_sample_size in struct perf_event_attr.  The
491sample size is limited by the maximum event size which is 64KiB.  It is
492difficult to know how big the event might be without the trace sample attached,
493but the tool validates that the sample size is not greater than 60KiB.
494
495
496new snapshot option
497~~~~~~~~~~~~~~~~~~~
498
499The difference between full trace and snapshot from the kernel's perspective is
500that in full trace we don't overwrite trace data that the user hasn't collected
501yet (and indicated that by advancing aux_tail), whereas in snapshot mode we let
502the trace run and overwrite older data in the buffer so that whenever something
503interesting happens, we can stop it and grab a snapshot of what was going on
504around that interesting moment.
505
506To select snapshot mode a new option has been added:
507
508	-S
509
510Optionally it can be followed by the snapshot size e.g.
511
512	-S0x100000
513
514The default snapshot size is the auxtrace mmap size.  If neither auxtrace mmap size
515nor snapshot size is specified, then the default is 4MiB for privileged users
516(or if /proc/sys/kernel/perf_event_paranoid < 0), 128KiB for unprivileged users.
517If an unprivileged user does not specify mmap pages, the mmap pages will be
518reduced as described in the 'new auxtrace mmap size option' section below.
519
520The snapshot size is displayed if the option -vv is used e.g.
521
522	Intel PT snapshot size: %zu
523
524
525new auxtrace mmap size option
526~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
527
528Intel PT buffer size is specified by an addition to the -m option e.g.
529
530	-m,16
531
532selects a buffer size of 16 pages i.e. 64KiB.
533
534Note that the existing functionality of -m is unchanged.  The auxtrace mmap size
535is specified by the optional addition of a comma and the value.
536
537The default auxtrace mmap size for Intel PT is 4MiB/page_size for privileged users
538(or if /proc/sys/kernel/perf_event_paranoid < 0), 128KiB for unprivileged users.
539If an unprivileged user does not specify mmap pages, the mmap pages will be
540reduced from the default 512KiB/page_size to 256KiB/page_size, otherwise the
541user is likely to get an error as they exceed their mlock limit (Max locked
542memory as shown in /proc/self/limits).  Note that perf does not count the first
543512KiB (actually /proc/sys/kernel/perf_event_mlock_kb minus 1 page) per cpu
544against the mlock limit so an unprivileged user is allowed 512KiB per cpu plus
545their mlock limit (which defaults to 64KiB but is not multiplied by the number
546of cpus).
547
548In full-trace mode, powers of two are allowed for buffer size, with a minimum
549size of 2 pages.  In snapshot mode or sampling mode, it is the same but the
550minimum size is 1 page.
551
552The mmap size and auxtrace mmap size are displayed if the -vv option is used e.g.
553
554	mmap length 528384
555	auxtrace mmap length 4198400
556
557
558Intel PT modes of operation
559~~~~~~~~~~~~~~~~~~~~~~~~~~~
560
561Intel PT can be used in 2 modes:
562	full-trace mode
563	sample mode
564	snapshot mode
565
566Full-trace mode traces continuously e.g.
567
568	perf record -e intel_pt//u uname
569
570Sample mode attaches a Intel PT sample to other events e.g.
571
572	perf record --aux-sample -e intel_pt//u -e branch-misses:u
573
574Snapshot mode captures the available data when a signal is sent e.g.
575
576	perf record -v -e intel_pt//u -S ./loopy 1000000000 &
577	[1] 11435
578	kill -USR2 11435
579	Recording AUX area tracing snapshot
580
581Note that the signal sent is SIGUSR2.
582Note that "Recording AUX area tracing snapshot" is displayed because the -v
583option is used.
584
585The 2 modes cannot be used together.
586
587
588Buffer handling
589~~~~~~~~~~~~~~~
590
591There may be buffer limitations (i.e. single ToPa entry) which means that actual
592buffer sizes are limited to powers of 2 up to 4MiB (MAX_ORDER).  In order to
593provide other sizes, and in particular an arbitrarily large size, multiple
594buffers are logically concatenated.  However an interrupt must be used to switch
595between buffers.  That has two potential problems:
596	a) the interrupt may not be handled in time so that the current buffer
597	becomes full and some trace data is lost.
598	b) the interrupts may slow the system and affect the performance
599	results.
600
601If trace data is lost, the driver sets 'truncated' in the PERF_RECORD_AUX event
602which the tools report as an error.
603
604In full-trace mode, the driver waits for data to be copied out before allowing
605the (logical) buffer to wrap-around.  If data is not copied out quickly enough,
606again 'truncated' is set in the PERF_RECORD_AUX event.  If the driver has to
607wait, the intel_pt event gets disabled.  Because it is difficult to know when
608that happens, perf tools always re-enable the intel_pt event after copying out
609data.
610
611
612Intel PT and build ids
613~~~~~~~~~~~~~~~~~~~~~~
614
615By default "perf record" post-processes the event stream to find all build ids
616for executables for all addresses sampled.  Deliberately, Intel PT is not
617decoded for that purpose (it would take too long).  Instead the build ids for
618all executables encountered (due to mmap, comm or task events) are included
619in the perf.data file.
620
621To see buildids included in the perf.data file use the command:
622
623	perf buildid-list
624
625If the perf.data file contains Intel PT data, that is the same as:
626
627	perf buildid-list --with-hits
628
629
630Snapshot mode and event disabling
631~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
632
633In order to make a snapshot, the intel_pt event is disabled using an IOCTL,
634namely PERF_EVENT_IOC_DISABLE.  However doing that can also disable the
635collection of side-band information.  In order to prevent that,  a dummy
636software event has been introduced that permits tracking events (like mmaps) to
637continue to be recorded while intel_pt is disabled.  That is important to ensure
638there is complete side-band information to allow the decoding of subsequent
639snapshots.
640
641A test has been created for that.  To find the test:
642
643	perf test list
644	...
645	23: Test using a dummy software event to keep tracking
646
647To run the test:
648
649	perf test 23
650	23: Test using a dummy software event to keep tracking     : Ok
651
652
653perf record modes (nothing new here)
654~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
655
656perf record essentially operates in one of three modes:
657	per thread
658	per cpu
659	workload only
660
661"per thread" mode is selected by -t or by --per-thread (with -p or -u or just a
662workload).
663"per cpu" is selected by -C or -a.
664"workload only" mode is selected by not using the other options but providing a
665command to run (i.e. the workload).
666
667In per-thread mode an exact list of threads is traced.  There is no inheritance.
668Each thread has its own event buffer.
669
670In per-cpu mode all processes (or processes from the selected cgroup i.e. -G
671option, or processes selected with -p or -u) are traced.  Each cpu has its own
672buffer. Inheritance is allowed.
673
674In workload-only mode, the workload is traced but with per-cpu buffers.
675Inheritance is allowed.  Note that you can now trace a workload in per-thread
676mode by using the --per-thread option.
677
678
679Privileged vs non-privileged users
680~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
681
682Unless /proc/sys/kernel/perf_event_paranoid is set to -1, unprivileged users
683have memory limits imposed upon them.  That affects what buffer sizes they can
684have as outlined above.
685
686The v4.2 kernel introduced support for a context switch metadata event,
687PERF_RECORD_SWITCH, which allows unprivileged users to see when their processes
688are scheduled out and in, just not by whom, which is left for the
689PERF_RECORD_SWITCH_CPU_WIDE, that is only accessible in system wide context,
690which in turn requires CAP_SYS_ADMIN.
691
692Please see the 45ac1403f564 ("perf: Add PERF_RECORD_SWITCH to indicate context
693switches") commit, that introduces these metadata events for further info.
694
695When working with kernels < v4.2, the following considerations must be taken,
696as the sched:sched_switch tracepoints will be used to receive such information:
697
698Unless /proc/sys/kernel/perf_event_paranoid is set to -1, unprivileged users are
699not permitted to use tracepoints which means there is insufficient side-band
700information to decode Intel PT in per-cpu mode, and potentially workload-only
701mode too if the workload creates new processes.
702
703Note also, that to use tracepoints, read-access to debugfs is required.  So if
704debugfs is not mounted or the user does not have read-access, it will again not
705be possible to decode Intel PT in per-cpu mode.
706
707
708sched_switch tracepoint
709~~~~~~~~~~~~~~~~~~~~~~~
710
711The sched_switch tracepoint is used to provide side-band data for Intel PT
712decoding in kernels where the PERF_RECORD_SWITCH metadata event isn't
713available.
714
715The sched_switch events are automatically added. e.g. the second event shown
716below:
717
718	$ perf record -vv -e intel_pt//u uname
719	------------------------------------------------------------
720	perf_event_attr:
721	type                             6
722	size                             112
723	config                           0x400
724	{ sample_period, sample_freq }   1
725	sample_type                      IP|TID|TIME|CPU|IDENTIFIER
726	read_format                      ID
727	disabled                         1
728	inherit                          1
729	exclude_kernel                   1
730	exclude_hv                       1
731	enable_on_exec                   1
732	sample_id_all                    1
733	------------------------------------------------------------
734	sys_perf_event_open: pid 31104  cpu 0  group_fd -1  flags 0x8
735	sys_perf_event_open: pid 31104  cpu 1  group_fd -1  flags 0x8
736	sys_perf_event_open: pid 31104  cpu 2  group_fd -1  flags 0x8
737	sys_perf_event_open: pid 31104  cpu 3  group_fd -1  flags 0x8
738	------------------------------------------------------------
739	perf_event_attr:
740	type                             2
741	size                             112
742	config                           0x108
743	{ sample_period, sample_freq }   1
744	sample_type                      IP|TID|TIME|CPU|PERIOD|RAW|IDENTIFIER
745	read_format                      ID
746	inherit                          1
747	sample_id_all                    1
748	exclude_guest                    1
749	------------------------------------------------------------
750	sys_perf_event_open: pid -1  cpu 0  group_fd -1  flags 0x8
751	sys_perf_event_open: pid -1  cpu 1  group_fd -1  flags 0x8
752	sys_perf_event_open: pid -1  cpu 2  group_fd -1  flags 0x8
753	sys_perf_event_open: pid -1  cpu 3  group_fd -1  flags 0x8
754	------------------------------------------------------------
755	perf_event_attr:
756	type                             1
757	size                             112
758	config                           0x9
759	{ sample_period, sample_freq }   1
760	sample_type                      IP|TID|TIME|IDENTIFIER
761	read_format                      ID
762	disabled                         1
763	inherit                          1
764	exclude_kernel                   1
765	exclude_hv                       1
766	mmap                             1
767	comm                             1
768	enable_on_exec                   1
769	task                             1
770	sample_id_all                    1
771	mmap2                            1
772	comm_exec                        1
773	------------------------------------------------------------
774	sys_perf_event_open: pid 31104  cpu 0  group_fd -1  flags 0x8
775	sys_perf_event_open: pid 31104  cpu 1  group_fd -1  flags 0x8
776	sys_perf_event_open: pid 31104  cpu 2  group_fd -1  flags 0x8
777	sys_perf_event_open: pid 31104  cpu 3  group_fd -1  flags 0x8
778	mmap size 528384B
779	AUX area mmap length 4194304
780	perf event ring buffer mmapped per cpu
781	Synthesizing auxtrace information
782	Linux
783	[ perf record: Woken up 1 times to write data ]
784	[ perf record: Captured and wrote 0.042 MB perf.data ]
785
786Note, the sched_switch event is only added if the user is permitted to use it
787and only in per-cpu mode.
788
789Note also, the sched_switch event is only added if TSC packets are requested.
790That is because, in the absence of timing information, the sched_switch events
791cannot be matched against the Intel PT trace.
792
793
794perf script
795-----------
796
797By default, perf script will decode trace data found in the perf.data file.
798This can be further controlled by new option --itrace.
799
800
801New --itrace option
802~~~~~~~~~~~~~~~~~~~
803
804Having no option is the same as
805
806	--itrace
807
808which, in turn, is the same as
809
810	--itrace=cepwx
811
812The letters are:
813
814	i	synthesize "instructions" events
815	b	synthesize "branches" events
816	x	synthesize "transactions" events
817	w	synthesize "ptwrite" events
818	p	synthesize "power" events
819	c	synthesize branches events (calls only)
820	r	synthesize branches events (returns only)
821	e	synthesize tracing error events
822	d	create a debug log
823	g	synthesize a call chain (use with i or x)
824	l	synthesize last branch entries (use with i or x)
825	s	skip initial number of events
826
827"Instructions" events look like they were recorded by "perf record -e
828instructions".
829
830"Branches" events look like they were recorded by "perf record -e branches". "c"
831and "r" can be combined to get calls and returns.
832
833"Transactions" events correspond to the start or end of transactions. The
834'flags' field can be used in perf script to determine whether the event is a
835tranasaction start, commit or abort.
836
837Note that "instructions", "branches" and "transactions" events depend on code
838flow packets which can be disabled by using the config term "branch=0".  Refer
839to the config terms section above.
840
841"ptwrite" events record the payload of the ptwrite instruction and whether
842"fup_on_ptw" was used.  "ptwrite" events depend on PTWRITE packets which are
843recorded only if the "ptw" config term was used.  Refer to the config terms
844section above.  perf script "synth" field displays "ptwrite" information like
845this: "ip: 0 payload: 0x123456789abcdef0"  where "ip" is 1 if "fup_on_ptw" was
846used.
847
848"Power" events correspond to power event packets and CBR (core-to-bus ratio)
849packets.  While CBR packets are always recorded when tracing is enabled, power
850event packets are recorded only if the "pwr_evt" config term was used.  Refer to
851the config terms section above.  The power events record information about
852C-state changes, whereas CBR is indicative of CPU frequency.  perf script
853"event,synth" fields display information like this:
854	cbr:  cbr: 22 freq: 2189 MHz (200%)
855	mwait:  hints: 0x60 extensions: 0x1
856	pwre:  hw: 0 cstate: 2 sub-cstate: 0
857	exstop:  ip: 1
858	pwrx:  deepest cstate: 2 last cstate: 2 wake reason: 0x4
859Where:
860	"cbr" includes the frequency and the percentage of maximum non-turbo
861	"mwait" shows mwait hints and extensions
862	"pwre" shows C-state transitions (to a C-state deeper than C0) and
863	whether	initiated by hardware
864	"exstop" indicates execution stopped and whether the IP was recorded
865	exactly,
866	"pwrx" indicates return to C0
867For more details refer to the Intel 64 and IA-32 Architectures Software
868Developer Manuals.
869
870Error events show where the decoder lost the trace.  Error events
871are quite important.  Users must know if what they are seeing is a complete
872picture or not.
873
874The "d" option will cause the creation of a file "intel_pt.log" containing all
875decoded packets and instructions.  Note that this option slows down the decoder
876and that the resulting file may be very large.
877
878In addition, the period of the "instructions" event can be specified. e.g.
879
880	--itrace=i10us
881
882sets the period to 10us i.e. one  instruction sample is synthesized for each 10
883microseconds of trace.  Alternatives to "us" are "ms" (milliseconds),
884"ns" (nanoseconds), "t" (TSC ticks) or "i" (instructions).
885
886"ms", "us" and "ns" are converted to TSC ticks.
887
888The timing information included with Intel PT does not give the time of every
889instruction.  Consequently, for the purpose of sampling, the decoder estimates
890the time since the last timing packet based on 1 tick per instruction.  The time
891on the sample is *not* adjusted and reflects the last known value of TSC.
892
893For Intel PT, the default period is 100us.
894
895Setting it to a zero period means "as often as possible".
896
897In the case of Intel PT that is the same as a period of 1 and a unit of
898'instructions' (i.e. --itrace=i1i).
899
900Also the call chain size (default 16, max. 1024) for instructions or
901transactions events can be specified. e.g.
902
903	--itrace=ig32
904	--itrace=xg32
905
906Also the number of last branch entries (default 64, max. 1024) for instructions or
907transactions events can be specified. e.g.
908
909       --itrace=il10
910       --itrace=xl10
911
912Note that last branch entries are cleared for each sample, so there is no overlap
913from one sample to the next.
914
915To disable trace decoding entirely, use the option --no-itrace.
916
917It is also possible to skip events generated (instructions, branches, transactions)
918at the beginning. This is useful to ignore initialization code.
919
920	--itrace=i0nss1000000
921
922skips the first million instructions.
923
924dump option
925~~~~~~~~~~~
926
927perf script has an option (-D) to "dump" the events i.e. display the binary
928data.
929
930When -D is used, Intel PT packets are displayed.  The packet decoder does not
931pay attention to PSB packets, but just decodes the bytes - so the packets seen
932by the actual decoder may not be identical in places where the data is corrupt.
933One example of that would be when the buffer-switching interrupt has been too
934slow, and the buffer has been filled completely.  In that case, the last packet
935in the buffer might be truncated and immediately followed by a PSB as the trace
936continues in the next buffer.
937
938To disable the display of Intel PT packets, combine the -D option with
939--no-itrace.
940
941
942perf report
943-----------
944
945By default, perf report will decode trace data found in the perf.data file.
946This can be further controlled by new option --itrace exactly the same as
947perf script, with the exception that the default is --itrace=igxe.
948
949
950perf inject
951-----------
952
953perf inject also accepts the --itrace option in which case tracing data is
954removed and replaced with the synthesized events. e.g.
955
956	perf inject --itrace -i perf.data -o perf.data.new
957
958Below is an example of using Intel PT with autofdo.  It requires autofdo
959(https://github.com/google/autofdo) and gcc version 5.  The bubble
960sort example is from the AutoFDO tutorial (https://gcc.gnu.org/wiki/AutoFDO/Tutorial)
961amended to take the number of elements as a parameter.
962
963	$ gcc-5 -O3 sort.c -o sort_optimized
964	$ ./sort_optimized 30000
965	Bubble sorting array of 30000 elements
966	2254 ms
967
968	$ cat ~/.perfconfig
969	[intel-pt]
970		mispred-all = on
971
972	$ perf record -e intel_pt//u ./sort 3000
973	Bubble sorting array of 3000 elements
974	58 ms
975	[ perf record: Woken up 2 times to write data ]
976	[ perf record: Captured and wrote 3.939 MB perf.data ]
977	$ perf inject -i perf.data -o inj --itrace=i100usle --strip
978	$ ./create_gcov --binary=./sort --profile=inj --gcov=sort.gcov -gcov_version=1
979	$ gcc-5 -O3 -fauto-profile=sort.gcov sort.c -o sort_autofdo
980	$ ./sort_autofdo 30000
981	Bubble sorting array of 30000 elements
982	2155 ms
983
984Note there is currently no advantage to using Intel PT instead of LBR, but
985that may change in the future if greater use is made of the data.
986
987
988PEBS via Intel PT
989-----------------
990
991Some hardware has the feature to redirect PEBS records to the Intel PT trace.
992Recording is selected by using the aux-output config term e.g.
993
994	perf record -c 10000 -e '{intel_pt/branch=0/,cycles/aux-output/ppp}' uname
995
996Note that currently, software only supports redirecting at most one PEBS event.
997
998To display PEBS events from the Intel PT trace, use the itrace 'o' option e.g.
999
1000	perf script --itrace=oe
1001
1002
1003SEE ALSO
1004--------
1005
1006linkperf:perf-record[1], linkperf:perf-script[1], linkperf:perf-report[1],
1007linkperf:perf-inject[1]
1008