Loading...
Note: File does not exist in v4.17.
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. 'perf record' can make a copy of /proc/kcore if the option
73--kcore is used, but access to /proc/kcore is restricted e.g.
74
75 sudo perf record -o pt_ls --kcore -e intel_pt// -- ls
76
77which will create a directory named 'pt_ls' and put the perf.data file (named
78simply 'data') and copies of /proc/kcore, /proc/kallsyms and /proc/modules into
79it. The other tools understand the directory format, so to use 'perf report'
80becomes:
81
82 sudo perf report -i 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 sudo perf 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_PERFMON or 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 G synthesize a call chain on existing event records
825 l synthesize last branch entries (use with i or x)
826 L synthesize last branch entries on existing event records
827 s skip initial number of events
828 q quicker (less detailed) decoding
829
830"Instructions" events look like they were recorded by "perf record -e
831instructions".
832
833"Branches" events look like they were recorded by "perf record -e branches". "c"
834and "r" can be combined to get calls and returns.
835
836"Transactions" events correspond to the start or end of transactions. The
837'flags' field can be used in perf script to determine whether the event is a
838tranasaction start, commit or abort.
839
840Note that "instructions", "branches" and "transactions" events depend on code
841flow packets which can be disabled by using the config term "branch=0". Refer
842to the config terms section above.
843
844"ptwrite" events record the payload of the ptwrite instruction and whether
845"fup_on_ptw" was used. "ptwrite" events depend on PTWRITE packets which are
846recorded only if the "ptw" config term was used. Refer to the config terms
847section above. perf script "synth" field displays "ptwrite" information like
848this: "ip: 0 payload: 0x123456789abcdef0" where "ip" is 1 if "fup_on_ptw" was
849used.
850
851"Power" events correspond to power event packets and CBR (core-to-bus ratio)
852packets. While CBR packets are always recorded when tracing is enabled, power
853event packets are recorded only if the "pwr_evt" config term was used. Refer to
854the config terms section above. The power events record information about
855C-state changes, whereas CBR is indicative of CPU frequency. perf script
856"event,synth" fields display information like this:
857 cbr: cbr: 22 freq: 2189 MHz (200%)
858 mwait: hints: 0x60 extensions: 0x1
859 pwre: hw: 0 cstate: 2 sub-cstate: 0
860 exstop: ip: 1
861 pwrx: deepest cstate: 2 last cstate: 2 wake reason: 0x4
862Where:
863 "cbr" includes the frequency and the percentage of maximum non-turbo
864 "mwait" shows mwait hints and extensions
865 "pwre" shows C-state transitions (to a C-state deeper than C0) and
866 whether initiated by hardware
867 "exstop" indicates execution stopped and whether the IP was recorded
868 exactly,
869 "pwrx" indicates return to C0
870For more details refer to the Intel 64 and IA-32 Architectures Software
871Developer Manuals.
872
873Error events show where the decoder lost the trace. Error events
874are quite important. Users must know if what they are seeing is a complete
875picture or not. The "e" option may be followed by flags which affect what errors
876will or will not be reported. Each flag must be preceded by either '+' or '-'.
877The flags supported by Intel PT are:
878 -o Suppress overflow errors
879 -l Suppress trace data lost errors
880For example, for errors but not overflow or data lost errors:
881
882 --itrace=e-o-l
883
884The "d" option will cause the creation of a file "intel_pt.log" containing all
885decoded packets and instructions. Note that this option slows down the decoder
886and that the resulting file may be very large. The "d" option may be followed
887by flags which affect what debug messages will or will not be logged. Each flag
888must be preceded by either '+' or '-'. The flags support by Intel PT are:
889 -a Suppress logging of perf events
890 +a Log all perf events
891By default, logged perf events are filtered by any specified time ranges, but
892flag +a overrides that.
893
894In addition, the period of the "instructions" event can be specified. e.g.
895
896 --itrace=i10us
897
898sets the period to 10us i.e. one instruction sample is synthesized for each 10
899microseconds of trace. Alternatives to "us" are "ms" (milliseconds),
900"ns" (nanoseconds), "t" (TSC ticks) or "i" (instructions).
901
902"ms", "us" and "ns" are converted to TSC ticks.
903
904The timing information included with Intel PT does not give the time of every
905instruction. Consequently, for the purpose of sampling, the decoder estimates
906the time since the last timing packet based on 1 tick per instruction. The time
907on the sample is *not* adjusted and reflects the last known value of TSC.
908
909For Intel PT, the default period is 100us.
910
911Setting it to a zero period means "as often as possible".
912
913In the case of Intel PT that is the same as a period of 1 and a unit of
914'instructions' (i.e. --itrace=i1i).
915
916Also the call chain size (default 16, max. 1024) for instructions or
917transactions events can be specified. e.g.
918
919 --itrace=ig32
920 --itrace=xg32
921
922Also the number of last branch entries (default 64, max. 1024) for instructions or
923transactions events can be specified. e.g.
924
925 --itrace=il10
926 --itrace=xl10
927
928Note that last branch entries are cleared for each sample, so there is no overlap
929from one sample to the next.
930
931The G and L options are designed in particular for sample mode, and work much
932like g and l but add call chain and branch stack to the other selected events
933instead of synthesized events. For example, to record branch-misses events for
934'ls' and then add a call chain derived from the Intel PT trace:
935
936 perf record --aux-sample -e '{intel_pt//u,branch-misses:u}' -- ls
937 perf report --itrace=Ge
938
939Although in fact G is a default for perf report, so that is the same as just:
940
941 perf report
942
943One caveat with the G and L options is that they work poorly with "Large PEBS".
944Large PEBS means PEBS records will be accumulated by hardware and the written
945into the event buffer in one go. That reduces interrupts, but can give very
946late timestamps. Because the Intel PT trace is synchronized by timestamps,
947the PEBS events do not match the trace. Currently, Large PEBS is used only in
948certain circumstances:
949 - hardware supports it
950 - PEBS is used
951 - event period is specified, instead of frequency
952 - the sample type is limited to the following flags:
953 PERF_SAMPLE_IP | PERF_SAMPLE_TID | PERF_SAMPLE_ADDR |
954 PERF_SAMPLE_ID | PERF_SAMPLE_CPU | PERF_SAMPLE_STREAM_ID |
955 PERF_SAMPLE_DATA_SRC | PERF_SAMPLE_IDENTIFIER |
956 PERF_SAMPLE_TRANSACTION | PERF_SAMPLE_PHYS_ADDR |
957 PERF_SAMPLE_REGS_INTR | PERF_SAMPLE_REGS_USER |
958 PERF_SAMPLE_PERIOD (and sometimes) | PERF_SAMPLE_TIME
959Because Intel PT sample mode uses a different sample type to the list above,
960Large PEBS is not used with Intel PT sample mode. To avoid Large PEBS in other
961cases, avoid specifying the event period i.e. avoid the 'perf record' -c option,
962--count option, or 'period' config term.
963
964To disable trace decoding entirely, use the option --no-itrace.
965
966It is also possible to skip events generated (instructions, branches, transactions)
967at the beginning. This is useful to ignore initialization code.
968
969 --itrace=i0nss1000000
970
971skips the first million instructions.
972
973The q option changes the way the trace is decoded. The decoding is much faster
974but much less detailed. Specifically, with the q option, the decoder does not
975decode TNT packets, and does not walk object code, but gets the ip from FUP and
976TIP packets. The q option can be used with the b and i options but the period
977is not used. The q option decodes more quickly, but is useful only if the
978control flow of interest is represented or indicated by FUP, TIP, TIP.PGE, or
979TIP.PGD packets (refer below). However the q option could be used to find time
980ranges that could then be decoded fully using the --time option.
981
982What will *not* be decoded with the (single) q option:
983
984 - direct calls and jmps
985 - conditional branches
986 - non-branch instructions
987
988What *will* be decoded with the (single) q option:
989
990 - asynchronous branches such as interrupts
991 - indirect branches
992 - function return target address *if* the noretcomp config term (refer
993 config terms section) was used
994 - start of (control-flow) tracing
995 - end of (control-flow) tracing, if it is not out of context
996 - power events, ptwrite, transaction start and abort
997 - instruction pointer associated with PSB packets
998
999Note the q option does not specify what events will be synthesized e.g. the p
1000option must be used also to show power events.
1001
1002Repeating the q option (double-q i.e. qq) results in even faster decoding and even
1003less detail. The decoder decodes only extended PSB (PSB+) packets, getting the
1004instruction pointer if there is a FUP packet within PSB+ (i.e. between PSB and
1005PSBEND). Note PSB packets occur regularly in the trace based on the psb_period
1006config term (refer config terms section). There will be a FUP packet if the
1007PSB+ occurs while control flow is being traced.
1008
1009What will *not* be decoded with the qq option:
1010
1011 - everything except instruction pointer associated with PSB packets
1012
1013What *will* be decoded with the qq option:
1014
1015 - instruction pointer associated with PSB packets
1016
1017
1018dump option
1019~~~~~~~~~~~
1020
1021perf script has an option (-D) to "dump" the events i.e. display the binary
1022data.
1023
1024When -D is used, Intel PT packets are displayed. The packet decoder does not
1025pay attention to PSB packets, but just decodes the bytes - so the packets seen
1026by the actual decoder may not be identical in places where the data is corrupt.
1027One example of that would be when the buffer-switching interrupt has been too
1028slow, and the buffer has been filled completely. In that case, the last packet
1029in the buffer might be truncated and immediately followed by a PSB as the trace
1030continues in the next buffer.
1031
1032To disable the display of Intel PT packets, combine the -D option with
1033--no-itrace.
1034
1035
1036perf report
1037-----------
1038
1039By default, perf report will decode trace data found in the perf.data file.
1040This can be further controlled by new option --itrace exactly the same as
1041perf script, with the exception that the default is --itrace=igxe.
1042
1043
1044perf inject
1045-----------
1046
1047perf inject also accepts the --itrace option in which case tracing data is
1048removed and replaced with the synthesized events. e.g.
1049
1050 perf inject --itrace -i perf.data -o perf.data.new
1051
1052Below is an example of using Intel PT with autofdo. It requires autofdo
1053(https://github.com/google/autofdo) and gcc version 5. The bubble
1054sort example is from the AutoFDO tutorial (https://gcc.gnu.org/wiki/AutoFDO/Tutorial)
1055amended to take the number of elements as a parameter.
1056
1057 $ gcc-5 -O3 sort.c -o sort_optimized
1058 $ ./sort_optimized 30000
1059 Bubble sorting array of 30000 elements
1060 2254 ms
1061
1062 $ cat ~/.perfconfig
1063 [intel-pt]
1064 mispred-all = on
1065
1066 $ perf record -e intel_pt//u ./sort 3000
1067 Bubble sorting array of 3000 elements
1068 58 ms
1069 [ perf record: Woken up 2 times to write data ]
1070 [ perf record: Captured and wrote 3.939 MB perf.data ]
1071 $ perf inject -i perf.data -o inj --itrace=i100usle --strip
1072 $ ./create_gcov --binary=./sort --profile=inj --gcov=sort.gcov -gcov_version=1
1073 $ gcc-5 -O3 -fauto-profile=sort.gcov sort.c -o sort_autofdo
1074 $ ./sort_autofdo 30000
1075 Bubble sorting array of 30000 elements
1076 2155 ms
1077
1078Note there is currently no advantage to using Intel PT instead of LBR, but
1079that may change in the future if greater use is made of the data.
1080
1081
1082PEBS via Intel PT
1083-----------------
1084
1085Some hardware has the feature to redirect PEBS records to the Intel PT trace.
1086Recording is selected by using the aux-output config term e.g.
1087
1088 perf record -c 10000 -e '{intel_pt/branch=0/,cycles/aux-output/ppp}' uname
1089
1090Note that currently, software only supports redirecting at most one PEBS event.
1091
1092To display PEBS events from the Intel PT trace, use the itrace 'o' option e.g.
1093
1094 perf script --itrace=oe
1095
1096
1097SEE ALSO
1098--------
1099
1100linkperf:perf-record[1], linkperf:perf-script[1], linkperf:perf-report[1],
1101linkperf:perf-inject[1]