7 Intel Processor Trace (Intel PT) is an extension of Intel Architecture that
8 collects information about software execution such as control flow, execution
9 modes and timings and formats it into highly compressed binary packets.
10 Technical details are documented in the Intel 64 and IA-32 Architectures
11 Software Developer Manuals, Chapter 36 Intel Processor Trace.
13 Intel PT is first supported in Intel Core M and 5th generation Intel Core
14 processors that are based on the Intel micro-architecture code name Broadwell.
16 Trace data is collected by 'perf record' and stored within the perf.data file.
17 See below for options to 'perf record'.
19 Trace data must be 'decoded' which involves walking the object code and matching
20 the trace data packets. For example a TNT packet only tells whether a
21 conditional branch was taken or not taken, so to make use of that packet the
22 decoder must know precisely which instruction was being executed.
24 Decoding is done on-the-fly. The decoder outputs samples in the same format as
25 samples output by perf hardware events, for example as though the "instructions"
26 or "branches" events had been recorded. Presently 3 tools support this:
27 'perf script', 'perf report' and 'perf inject'. See below for more information
30 The main distinguishing feature of Intel PT is that the decoder can determine
31 the exact flow of software execution. Intel PT can be used to understand why
32 and how did software get to a certain point, or behave a certain way. The
33 software does not have to be recompiled, so Intel PT works with debug or release
34 builds, however the executed images are needed - which makes use in JIT-compiled
35 environments, or with self-modified code, a challenge. Also symbols need to be
36 provided to make sense of addresses.
38 A limitation of Intel PT is that it produces huge amounts of trace data
39 (hundreds of megabytes per second per core) which takes a long time to decode,
40 for example two or three orders of magnitude longer than it took to collect.
41 Another limitation is the performance impact of tracing, something that will
42 vary depending on the use-case and architecture.
48 It is important to start small. That is because it is easy to capture vastly
49 more data than can possibly be processed.
51 The simplest thing to do with Intel PT is userspace profiling of small programs.
52 Data is captured with 'perf record' e.g. to trace 'ls' userspace-only:
54 perf record -e intel_pt//u ls
56 And profiled with 'perf report' e.g.
60 To also trace kernel space presents a problem, namely kernel self-modifying
61 code. A fairly good kernel image is available in /proc/kcore but to get an
62 accurate image a copy of /proc/kcore needs to be made under the same conditions
63 as the data capture. A script perf-with-kcore can do that, but beware that the
64 script makes use of 'sudo' to copy /proc/kcore. If you have perf installed
65 locally from the source tree you can do:
67 ~/libexec/perf-core/perf-with-kcore record pt_ls -e intel_pt// -- ls
69 which will create a directory named 'pt_ls' and put the perf.data file and
70 copies of /proc/kcore, /proc/kallsyms and /proc/modules into it. Then to use
71 'perf report' becomes:
73 ~/libexec/perf-core/perf-with-kcore report pt_ls
75 Because samples are synthesized after-the-fact, the sampling period can be
76 selected for reporting. e.g. sample every microsecond
78 ~/libexec/perf-core/perf-with-kcore report pt_ls --itrace=i1usge
80 See the sections below for more information about the --itrace option.
82 Beware the smaller the period, the more samples that are produced, and the
83 longer it takes to process them.
85 Also note that the coarseness of Intel PT timing information will start to
86 distort the statistical value of the sampling as the sampling period becomes
89 To represent software control flow, "branches" samples are produced. By default
90 a branch sample is synthesized for every single branch. To get an idea what
91 data is available you can use the 'perf script' tool with no parameters, which
92 will list all the samples.
94 perf record -e intel_pt//u ls
97 An interesting field that is not printed by default is 'flags' which can be
100 perf script -Fcomm,tid,pid,time,cpu,event,trace,ip,sym,dso,addr,symoff,flags
102 The flags are "bcrosyiABEx" which stand for branch, call, return, conditional,
103 system, asynchronous, interrupt, transaction abort, trace begin, trace end, and
104 in transaction, respectively.
106 While it is possible to create scripts to analyze the data, an alternative
107 approach is available to export the data to a postgresql database. Refer to
108 script export-to-postgresql.py for more details, and to script
109 call-graph-from-postgresql.py for an example of using the database.
111 As mentioned above, it is easy to capture too much data. One way to limit the
112 data captured is to use 'snapshot' mode which is explained further below.
113 Refer to 'new snapshot option' and 'Intel PT modes of operation' further below.
115 Another problem that will be experienced is decoder errors. They can be caused
116 by inability to access the executed image, self-modified or JIT-ed code, or the
117 inability to match side-band information (such as context switches and mmaps)
118 which results in the decoder not knowing what code was executed.
120 There is also the problem of perf not being able to copy the data fast enough,
121 resulting in data lost because the buffer was full. See 'Buffer handling' below
131 The Intel PT kernel driver creates a new PMU for Intel PT. PMU events are
132 selected by providing the PMU name followed by the "config" separated by slashes.
133 An enhancement has been made to allow default "config" e.g. the option
137 will use a default config value. Currently that is the same as
139 -e intel_pt/tsc,noretcomp=0/
143 -e intel_pt/tsc=1,noretcomp=0/
145 Note there are now new config terms - see section 'config terms' further below.
147 The config terms are listed in /sys/devices/intel_pt/format. They are bit
148 fields within the config member of the struct perf_event_attr which is
149 passed to the kernel by the perf_event_open system call. They correspond to bit
150 fields in the IA32_RTIT_CTL MSR. Here is a list of them and their definitions:
152 $ grep -H . /sys/bus/event_source/devices/intel_pt/format/*
153 /sys/bus/event_source/devices/intel_pt/format/cyc:config:1
154 /sys/bus/event_source/devices/intel_pt/format/cyc_thresh:config:19-22
155 /sys/bus/event_source/devices/intel_pt/format/mtc:config:9
156 /sys/bus/event_source/devices/intel_pt/format/mtc_period:config:14-17
157 /sys/bus/event_source/devices/intel_pt/format/noretcomp:config:11
158 /sys/bus/event_source/devices/intel_pt/format/psb_period:config:24-27
159 /sys/bus/event_source/devices/intel_pt/format/tsc:config:10
161 Note that the default config must be overridden for each term i.e.
163 -e intel_pt/noretcomp=0/
167 -e intel_pt/tsc=1,noretcomp=0/
169 So, to disable TSC packets use:
173 It is also possible to specify the config value explicitly:
175 -e intel_pt/config=0x400/
177 Note that, as with all events, the event is suffixed with event modifiers:
186 'h', 'G' and 'H' are for virtualization which is not supported by Intel PT.
187 'p' is also not relevant to Intel PT. So only options 'u' and 'k' are
188 meaningful for Intel PT.
190 perf_event_attr is displayed if the -vv option is used e.g.
192 ------------------------------------------------------------
197 { sample_period, sample_freq } 1
198 sample_type IP|TID|TIME|CPU|IDENTIFIER
206 ------------------------------------------------------------
207 sys_perf_event_open: pid 31104 cpu 0 group_fd -1 flags 0x8
208 sys_perf_event_open: pid 31104 cpu 1 group_fd -1 flags 0x8
209 sys_perf_event_open: pid 31104 cpu 2 group_fd -1 flags 0x8
210 sys_perf_event_open: pid 31104 cpu 3 group_fd -1 flags 0x8
211 ------------------------------------------------------------
217 The June 2015 version of Intel 64 and IA-32 Architectures Software Developer
218 Manuals, Chapter 36 Intel Processor Trace, defined new Intel PT features.
219 Some of the features are reflect in new config terms. All the config terms are
222 tsc Always supported. Produces TSC timestamp packets to provide
223 timing information. In some cases it is possible to decode
224 without timing information, for example a per-thread context
225 that does not overlap executable memory maps.
227 The default config selects tsc (i.e. tsc=1).
229 noretcomp Always supported. Disables "return compression" so a TIP packet
230 is produced when a function returns. Causes more packets to be
231 produced but might make decoding more reliable.
233 The default config does not select noretcomp (i.e. noretcomp=0).
235 psb_period Allows the frequency of PSB packets to be specified.
237 The PSB packet is a synchronization packet that provides a
238 starting point for decoding or recovery from errors.
240 Support for psb_period is indicated by:
242 /sys/bus/event_source/devices/intel_pt/caps/psb_cyc
244 which contains "1" if the feature is supported and "0"
247 Valid values are given by:
249 /sys/bus/event_source/devices/intel_pt/caps/psb_periods
251 which contains a hexadecimal value, the bits of which represent
252 valid values e.g. bit 2 set means value 2 is valid.
254 The psb_period value is converted to the approximate number of
255 trace bytes between PSB packets as:
259 e.g. value 3 means 16KiB bytes between PSBs
261 If an invalid value is entered, the error message
262 will give a list of valid values e.g.
264 $ perf record -e intel_pt/psb_period=15/u uname
265 Invalid psb_period for intel_pt. Valid values are: 0-5
267 If MTC packets are selected, the default config selects a value
268 of 3 (i.e. psb_period=3) or the nearest lower value that is
269 supported (0 is always supported). Otherwise the default is 0.
271 If decoding is expected to be reliable and the buffer is large
272 then a large PSB period can be used.
274 Because a TSC packet is produced with PSB, the PSB period can
275 also affect the granularity to timing information in the absence
278 mtc Produces MTC timing packets.
280 MTC packets provide finer grain timestamp information than TSC
281 packets. MTC packets record time using the hardware crystal
282 clock (CTC) which is related to TSC packets using a TMA packet.
284 Support for this feature is indicated by:
286 /sys/bus/event_source/devices/intel_pt/caps/mtc
288 which contains "1" if the feature is supported and
291 The frequency of MTC packets can also be specified - see
294 mtc_period Specifies how frequently MTC packets are produced - see mtc
295 above for how to determine if MTC packets are supported.
297 Valid values are given by:
299 /sys/bus/event_source/devices/intel_pt/caps/mtc_periods
301 which contains a hexadecimal value, the bits of which represent
302 valid values e.g. bit 2 set means value 2 is valid.
304 The mtc_period value is converted to the MTC frequency as:
306 CTC-frequency / (2 ^ value)
308 e.g. value 3 means one eighth of CTC-frequency
310 Where CTC is the hardware crystal clock, the frequency of which
311 can be related to TSC via values provided in cpuid leaf 0x15.
313 If an invalid value is entered, the error message
314 will give a list of valid values e.g.
316 $ perf record -e intel_pt/mtc_period=15/u uname
317 Invalid mtc_period for intel_pt. Valid values are: 0,3,6,9
319 The default value is 3 or the nearest lower value
320 that is supported (0 is always supported).
322 cyc Produces CYC timing packets.
324 CYC packets provide even finer grain timestamp information than
325 MTC and TSC packets. A CYC packet contains the number of CPU
326 cycles since the last CYC packet. Unlike MTC and TSC packets,
327 CYC packets are only sent when another packet is also sent.
329 Support for this feature is indicated by:
331 /sys/bus/event_source/devices/intel_pt/caps/psb_cyc
333 which contains "1" if the feature is supported and
336 The number of CYC packets produced can be reduced by specifying
337 a threshold - see cyc_thresh below.
339 cyc_thresh Specifies how frequently CYC packets are produced - see cyc
340 above for how to determine if CYC packets are supported.
342 Valid cyc_thresh values are given by:
344 /sys/bus/event_source/devices/intel_pt/caps/cycle_thresholds
346 which contains a hexadecimal value, the bits of which represent
347 valid values e.g. bit 2 set means value 2 is valid.
349 The cyc_thresh value represents the minimum number of CPU cycles
350 that must have passed before a CYC packet can be sent. The
351 number of CPU cycles is:
355 e.g. value 4 means 8 CPU cycles must pass before a CYC packet
356 can be sent. Note a CYC packet is still only sent when another
357 packet is sent, not at, e.g. every 8 CPU cycles.
359 If an invalid value is entered, the error message
360 will give a list of valid values e.g.
362 $ perf record -e intel_pt/cyc,cyc_thresh=15/u uname
363 Invalid cyc_thresh for intel_pt. Valid values are: 0-12
365 CYC packets are not requested by default.
367 pt Specifies pass-through which enables the 'branch' config term.
369 The default config selects 'pt' if it is available, so a user will
370 never need to specify this term.
372 branch Enable branch tracing. Branch tracing is enabled by default so to
373 disable branch tracing use 'branch=0'.
375 The default config selects 'branch' if it is available.
377 ptw Enable PTWRITE packets which are produced when a ptwrite instruction
380 Support for this feature is indicated by:
382 /sys/bus/event_source/devices/intel_pt/caps/ptwrite
384 which contains "1" if the feature is supported and
387 fup_on_ptw Enable a FUP packet to follow the PTWRITE packet. The FUP packet
388 provides the address of the ptwrite instruction. In the absence of
389 fup_on_ptw, the decoder will use the address of the previous branch
390 if branch tracing is enabled, otherwise the address will be zero.
391 Note that fup_on_ptw will work even when branch tracing is disabled.
393 pwr_evt Enable power events. The power events provide information about
394 changes to the CPU C-state.
396 Support for this feature is indicated by:
398 /sys/bus/event_source/devices/intel_pt/caps/power_event_trace
400 which contains "1" if the feature is supported and
407 The difference between full trace and snapshot from the kernel's perspective is
408 that in full trace we don't overwrite trace data that the user hasn't collected
409 yet (and indicated that by advancing aux_tail), whereas in snapshot mode we let
410 the trace run and overwrite older data in the buffer so that whenever something
411 interesting happens, we can stop it and grab a snapshot of what was going on
412 around that interesting moment.
414 To select snapshot mode a new option has been added:
418 Optionally it can be followed by the snapshot size e.g.
422 The default snapshot size is the auxtrace mmap size. If neither auxtrace mmap size
423 nor snapshot size is specified, then the default is 4MiB for privileged users
424 (or if /proc/sys/kernel/perf_event_paranoid < 0), 128KiB for unprivileged users.
425 If an unprivileged user does not specify mmap pages, the mmap pages will be
426 reduced as described in the 'new auxtrace mmap size option' section below.
428 The snapshot size is displayed if the option -vv is used e.g.
430 Intel PT snapshot size: %zu
433 new auxtrace mmap size option
434 ---------------------------
436 Intel PT buffer size is specified by an addition to the -m option e.g.
440 selects a buffer size of 16 pages i.e. 64KiB.
442 Note that the existing functionality of -m is unchanged. The auxtrace mmap size
443 is specified by the optional addition of a comma and the value.
445 The default auxtrace mmap size for Intel PT is 4MiB/page_size for privileged users
446 (or if /proc/sys/kernel/perf_event_paranoid < 0), 128KiB for unprivileged users.
447 If an unprivileged user does not specify mmap pages, the mmap pages will be
448 reduced from the default 512KiB/page_size to 256KiB/page_size, otherwise the
449 user is likely to get an error as they exceed their mlock limit (Max locked
450 memory as shown in /proc/self/limits). Note that perf does not count the first
451 512KiB (actually /proc/sys/kernel/perf_event_mlock_kb minus 1 page) per cpu
452 against the mlock limit so an unprivileged user is allowed 512KiB per cpu plus
453 their mlock limit (which defaults to 64KiB but is not multiplied by the number
456 In full-trace mode, powers of two are allowed for buffer size, with a minimum
457 size of 2 pages. In snapshot mode, it is the same but the minimum size is
460 The mmap size and auxtrace mmap size are displayed if the -vv option is used e.g.
463 auxtrace mmap length 4198400
466 Intel PT modes of operation
467 ---------------------------
469 Intel PT can be used in 2 modes:
473 Full-trace mode traces continuously e.g.
475 perf record -e intel_pt//u uname
477 Snapshot mode captures the available data when a signal is sent e.g.
479 perf record -v -e intel_pt//u -S ./loopy 1000000000 &
482 Recording AUX area tracing snapshot
484 Note that the signal sent is SIGUSR2.
485 Note that "Recording AUX area tracing snapshot" is displayed because the -v
488 The 2 modes cannot be used together.
494 There may be buffer limitations (i.e. single ToPa entry) which means that actual
495 buffer sizes are limited to powers of 2 up to 4MiB (MAX_ORDER). In order to
496 provide other sizes, and in particular an arbitrarily large size, multiple
497 buffers are logically concatenated. However an interrupt must be used to switch
498 between buffers. That has two potential problems:
499 a) the interrupt may not be handled in time so that the current buffer
500 becomes full and some trace data is lost.
501 b) the interrupts may slow the system and affect the performance
504 If trace data is lost, the driver sets 'truncated' in the PERF_RECORD_AUX event
505 which the tools report as an error.
507 In full-trace mode, the driver waits for data to be copied out before allowing
508 the (logical) buffer to wrap-around. If data is not copied out quickly enough,
509 again 'truncated' is set in the PERF_RECORD_AUX event. If the driver has to
510 wait, the intel_pt event gets disabled. Because it is difficult to know when
511 that happens, perf tools always re-enable the intel_pt event after copying out
515 Intel PT and build ids
516 ----------------------
518 By default "perf record" post-processes the event stream to find all build ids
519 for executables for all addresses sampled. Deliberately, Intel PT is not
520 decoded for that purpose (it would take too long). Instead the build ids for
521 all executables encountered (due to mmap, comm or task events) are included
522 in the perf.data file.
524 To see buildids included in the perf.data file use the command:
528 If the perf.data file contains Intel PT data, that is the same as:
530 perf buildid-list --with-hits
533 Snapshot mode and event disabling
534 ---------------------------------
536 In order to make a snapshot, the intel_pt event is disabled using an IOCTL,
537 namely PERF_EVENT_IOC_DISABLE. However doing that can also disable the
538 collection of side-band information. In order to prevent that, a dummy
539 software event has been introduced that permits tracking events (like mmaps) to
540 continue to be recorded while intel_pt is disabled. That is important to ensure
541 there is complete side-band information to allow the decoding of subsequent
544 A test has been created for that. To find the test:
548 23: Test using a dummy software event to keep tracking
553 23: Test using a dummy software event to keep tracking : Ok
556 perf record modes (nothing new here)
557 ------------------------------------
559 perf record essentially operates in one of three modes:
564 "per thread" mode is selected by -t or by --per-thread (with -p or -u or just a
566 "per cpu" is selected by -C or -a.
567 "workload only" mode is selected by not using the other options but providing a
568 command to run (i.e. the workload).
570 In per-thread mode an exact list of threads is traced. There is no inheritance.
571 Each thread has its own event buffer.
573 In per-cpu mode all processes (or processes from the selected cgroup i.e. -G
574 option, or processes selected with -p or -u) are traced. Each cpu has its own
575 buffer. Inheritance is allowed.
577 In workload-only mode, the workload is traced but with per-cpu buffers.
578 Inheritance is allowed. Note that you can now trace a workload in per-thread
579 mode by using the --per-thread option.
582 Privileged vs non-privileged users
583 ----------------------------------
585 Unless /proc/sys/kernel/perf_event_paranoid is set to -1, unprivileged users
586 have memory limits imposed upon them. That affects what buffer sizes they can
587 have as outlined above.
589 The v4.2 kernel introduced support for a context switch metadata event,
590 PERF_RECORD_SWITCH, which allows unprivileged users to see when their processes
591 are scheduled out and in, just not by whom, which is left for the
592 PERF_RECORD_SWITCH_CPU_WIDE, that is only accessible in system wide context,
593 which in turn requires CAP_SYS_ADMIN.
595 Please see the 45ac1403f564 ("perf: Add PERF_RECORD_SWITCH to indicate context
596 switches") commit, that introduces these metadata events for further info.
598 When working with kernels < v4.2, the following considerations must be taken,
599 as the sched:sched_switch tracepoints will be used to receive such information:
601 Unless /proc/sys/kernel/perf_event_paranoid is set to -1, unprivileged users are
602 not permitted to use tracepoints which means there is insufficient side-band
603 information to decode Intel PT in per-cpu mode, and potentially workload-only
604 mode too if the workload creates new processes.
606 Note also, that to use tracepoints, read-access to debugfs is required. So if
607 debugfs is not mounted or the user does not have read-access, it will again not
608 be possible to decode Intel PT in per-cpu mode.
611 sched_switch tracepoint
612 -----------------------
614 The sched_switch tracepoint is used to provide side-band data for Intel PT
615 decoding in kernels where the PERF_RECORD_SWITCH metadata event isn't
618 The sched_switch events are automatically added. e.g. the second event shown
621 $ perf record -vv -e intel_pt//u uname
622 ------------------------------------------------------------
627 { sample_period, sample_freq } 1
628 sample_type IP|TID|TIME|CPU|IDENTIFIER
636 ------------------------------------------------------------
637 sys_perf_event_open: pid 31104 cpu 0 group_fd -1 flags 0x8
638 sys_perf_event_open: pid 31104 cpu 1 group_fd -1 flags 0x8
639 sys_perf_event_open: pid 31104 cpu 2 group_fd -1 flags 0x8
640 sys_perf_event_open: pid 31104 cpu 3 group_fd -1 flags 0x8
641 ------------------------------------------------------------
646 { sample_period, sample_freq } 1
647 sample_type IP|TID|TIME|CPU|PERIOD|RAW|IDENTIFIER
652 ------------------------------------------------------------
653 sys_perf_event_open: pid -1 cpu 0 group_fd -1 flags 0x8
654 sys_perf_event_open: pid -1 cpu 1 group_fd -1 flags 0x8
655 sys_perf_event_open: pid -1 cpu 2 group_fd -1 flags 0x8
656 sys_perf_event_open: pid -1 cpu 3 group_fd -1 flags 0x8
657 ------------------------------------------------------------
662 { sample_period, sample_freq } 1
663 sample_type IP|TID|TIME|IDENTIFIER
676 ------------------------------------------------------------
677 sys_perf_event_open: pid 31104 cpu 0 group_fd -1 flags 0x8
678 sys_perf_event_open: pid 31104 cpu 1 group_fd -1 flags 0x8
679 sys_perf_event_open: pid 31104 cpu 2 group_fd -1 flags 0x8
680 sys_perf_event_open: pid 31104 cpu 3 group_fd -1 flags 0x8
682 AUX area mmap length 4194304
683 perf event ring buffer mmapped per cpu
684 Synthesizing auxtrace information
686 [ perf record: Woken up 1 times to write data ]
687 [ perf record: Captured and wrote 0.042 MB perf.data ]
689 Note, the sched_switch event is only added if the user is permitted to use it
690 and only in per-cpu mode.
692 Note also, the sched_switch event is only added if TSC packets are requested.
693 That is because, in the absence of timing information, the sched_switch events
694 cannot be matched against the Intel PT trace.
700 By default, perf script will decode trace data found in the perf.data file.
701 This can be further controlled by new option --itrace.
707 Having no option is the same as
711 which, in turn, is the same as
717 i synthesize "instructions" events
718 b synthesize "branches" events
719 x synthesize "transactions" events
720 c synthesize branches events (calls only)
721 r synthesize branches events (returns only)
722 e synthesize tracing error events
724 g synthesize a call chain (use with i or x)
725 l synthesize last branch entries (use with i or x)
726 s skip initial number of events
728 "Instructions" events look like they were recorded by "perf record -e
731 "Branches" events look like they were recorded by "perf record -e branches". "c"
732 and "r" can be combined to get calls and returns.
734 "Transactions" events correspond to the start or end of transactions. The
735 'flags' field can be used in perf script to determine whether the event is a
736 tranasaction start, commit or abort.
738 Error events are new. They show where the decoder lost the trace. Error events
739 are quite important. Users must know if what they are seeing is a complete
742 The "d" option will cause the creation of a file "intel_pt.log" containing all
743 decoded packets and instructions. Note that this option slows down the decoder
744 and that the resulting file may be very large.
746 In addition, the period of the "instructions" event can be specified. e.g.
750 sets the period to 10us i.e. one instruction sample is synthesized for each 10
751 microseconds of trace. Alternatives to "us" are "ms" (milliseconds),
752 "ns" (nanoseconds), "t" (TSC ticks) or "i" (instructions).
754 "ms", "us" and "ns" are converted to TSC ticks.
756 The timing information included with Intel PT does not give the time of every
757 instruction. Consequently, for the purpose of sampling, the decoder estimates
758 the time since the last timing packet based on 1 tick per instruction. The time
759 on the sample is *not* adjusted and reflects the last known value of TSC.
761 For Intel PT, the default period is 100us.
763 Setting it to a zero period means "as often as possible".
765 In the case of Intel PT that is the same as a period of 1 and a unit of
766 'instructions' (i.e. --itrace=i1i).
768 Also the call chain size (default 16, max. 1024) for instructions or
769 transactions events can be specified. e.g.
774 Also the number of last branch entries (default 64, max. 1024) for instructions or
775 transactions events can be specified. e.g.
780 Note that last branch entries are cleared for each sample, so there is no overlap
781 from one sample to the next.
783 To disable trace decoding entirely, use the option --no-itrace.
785 It is also possible to skip events generated (instructions, branches, transactions)
786 at the beginning. This is useful to ignore initialization code.
788 --itrace=i0nss1000000
790 skips the first million instructions.
795 perf script has an option (-D) to "dump" the events i.e. display the binary
798 When -D is used, Intel PT packets are displayed. The packet decoder does not
799 pay attention to PSB packets, but just decodes the bytes - so the packets seen
800 by the actual decoder may not be identical in places where the data is corrupt.
801 One example of that would be when the buffer-switching interrupt has been too
802 slow, and the buffer has been filled completely. In that case, the last packet
803 in the buffer might be truncated and immediately followed by a PSB as the trace
804 continues in the next buffer.
806 To disable the display of Intel PT packets, combine the -D option with
813 By default, perf report will decode trace data found in the perf.data file.
814 This can be further controlled by new option --itrace exactly the same as
815 perf script, with the exception that the default is --itrace=igxe.
821 perf inject also accepts the --itrace option in which case tracing data is
822 removed and replaced with the synthesized events. e.g.
824 perf inject --itrace -i perf.data -o perf.data.new
826 Below is an example of using Intel PT with autofdo. It requires autofdo
827 (https://github.com/google/autofdo) and gcc version 5. The bubble
828 sort example is from the AutoFDO tutorial (https://gcc.gnu.org/wiki/AutoFDO/Tutorial)
829 amended to take the number of elements as a parameter.
831 $ gcc-5 -O3 sort.c -o sort_optimized
832 $ ./sort_optimized 30000
833 Bubble sorting array of 30000 elements
840 $ perf record -e intel_pt//u ./sort 3000
841 Bubble sorting array of 3000 elements
843 [ perf record: Woken up 2 times to write data ]
844 [ perf record: Captured and wrote 3.939 MB perf.data ]
845 $ perf inject -i perf.data -o inj --itrace=i100usle --strip
846 $ ./create_gcov --binary=./sort --profile=inj --gcov=sort.gcov -gcov_version=1
847 $ gcc-5 -O3 -fauto-profile=sort.gcov sort.c -o sort_autofdo
848 $ ./sort_autofdo 30000
849 Bubble sorting array of 30000 elements
852 Note there is currently no advantage to using Intel PT instead of LBR, but
853 that may change in the future if greater use is made of the data.