6 perf-arm-spe - Support for Arm Statistical Profiling Extension within Perf tools
11 'perf record' -e arm_spe//
16 The SPE (Statistical Profiling Extension) feature provides accurate attribution of latencies and
17 events down to individual instructions. Rather than being interrupt-driven, it picks an
18 instruction to sample and then captures data for it during execution. Data includes execution time
19 in cycles. For loads and stores it also includes data address, cache miss events, and data origin.
21 The sampling has 5 stages:
23 1. Choose an operation
24 2. Collect data about the operation
25 3. Optionally discard the record based on a filter
26 4. Write the record to memory
27 5. Interrupt when the buffer is full
32 This is chosen from a sample population, for SPE this is an IMPLEMENTATION DEFINED choice of all
33 architectural instructions or all micro-ops. Sampling happens at a programmable interval. The
34 architecture provides a mechanism for the SPE driver to infer the minimum interval at which it should
35 sample. This minimum interval is used by the driver if no interval is specified. A pseudo-random
36 perturbation is also added to the sampling interval by default.
38 Collect data about the operation
39 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
41 Program counter, PMU events, timings and data addresses related to the operation are recorded.
42 Sampling ensures there is only one sampled operation is in flight.
44 Optionally discard the record based on a filter
45 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
47 Based on programmable criteria, choose whether to keep the record or discard it. If the record is
48 discarded then the flow stops here for this sample.
50 Write the record to memory
51 ~~~~~~~~~~~~~~~~~~~~~~~~~~
53 The record is appended to a memory buffer
55 Interrupt when the buffer is full
56 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
58 When the buffer fills, an interrupt is sent and the driver signals Perf to collect the records.
59 Perf saves the raw data in the perf.data file.
64 Up until this point no decoding of the SPE data was done by either the kernel or Perf. Only when the
65 recorded file is opened with 'perf report' or 'perf script' does the decoding happen. When decoding
66 the data, Perf generates "synthetic samples" as if these were generated at the time of the
67 recording. These samples are the same as if normal sampling was done by Perf without using SPE,
68 although they may have more attributes associated with them. For example a normal sample may have
69 just the instruction pointer, but an SPE sample can have data addresses and latency attributes.
74 - Sampling, rather than tracing, cuts down the profiling problem to something more manageable for
75 hardware. Only one sampled operation is in flight at a time.
77 - Allows precise attribution data, including: Full PC of instruction, data virtual and physical
80 - Allows correlation between an instruction and events, such as TLB and cache miss. (Data source
81 indicates which particular cache was hit, but the meaning is implementation defined because
82 different implementations can have different cache configurations.)
84 However, SPE does not provide any call-graph information, and relies on statistical methods.
89 When an operation is sampled while a previous sampled operation has not finished, a collision
90 occurs. The new sample is dropped. Collisions affect the integrity of the data, so the sample rate
91 should be set to avoid collisions.
93 The 'sample_collision' PMU event can be used to determine the number of lost samples. Although this
94 count is based on collisions _before_ filtering occurs. Therefore this can not be used as an exact
95 number for samples dropped that would have made it through the filter, but can be a rough
98 The effect of microarchitectural sampling
99 -----------------------------------------
101 If an implementation samples micro-operations instead of instructions, the results of sampling must
102 be weighted accordingly.
104 For example, if a given instruction A is always converted into two micro-operations, A0 and A1, it
105 becomes twice as likely to appear in the sample population.
107 The coarse effect of conversions, and, if applicable, sampling of speculative operations, can be
108 estimated from the 'sample_pop' and 'inst_retired' PMU events.
113 The ARM_SPE_PMU config must be set to build as either a module or statically.
115 Depending on CPU model, the kernel may need to be booted with page table isolation disabled
116 (kpti=off). If KPTI needs to be disabled, this will fail with a console message "profiling buffer
117 inaccessible. Try passing 'kpti=off' on the kernel command line".
119 Capturing SPE with perf command-line tools
120 ------------------------------------------
122 You can record a session with SPE samples:
124 perf record -e arm_spe// -- ./mybench
126 The sample period is set from the -c option, and because the minimum interval is used by default
127 it's recommended to set this to a higher value. The value is written to PMSIRR.INTERVAL.
132 These are placed between the // in the event and comma separated. For example '-e
133 arm_spe/load_filter=1,min_latency=10/'
135 branch_filter=1 - collect branches only (PMSFCR.B)
136 event_filter=<mask> - filter on specific events (PMSEVFR) - see bitfield description below
137 jitter=1 - use jitter to avoid resonance when sampling (PMSIRR.RND)
138 load_filter=1 - collect loads only (PMSFCR.LD)
139 min_latency=<n> - collect only samples with this latency or higher* (PMSLATFR)
140 pa_enable=1 - collect physical address (as well as VA) of loads/stores (PMSCR.PA) - requires privilege
141 pct_enable=1 - collect physical timestamp instead of virtual timestamp (PMSCR.PCT) - requires privilege
142 store_filter=1 - collect stores only (PMSFCR.ST)
143 ts_enable=1 - enable timestamping with value of generic timer (PMSCR.TS)
145 +++*+++ Latency is the total latency from the point at which sampling started on that instruction, rather
146 than only the execution latency.
148 Only some events can be filtered on; these include:
150 bit 1 - instruction retired (i.e. omit speculative instructions)
154 bit 11 - misaligned access
156 So to sample just retired instructions:
158 perf record -e arm_spe/event_filter=2/ -- ./mybench
160 or just mispredicted branches:
162 perf record -e arm_spe/event_filter=0x80/ -- ./mybench
167 By default perf report and perf script will assign samples to separate groups depending on the
168 attributes/events of the SPE record. Because instructions can have multiple events associated with
169 them, the samples in these groups are not necessarily unique. For example perf report shows these
185 The arm_spe// and dummy:u events are implementation details and are expected to be empty.
187 To get a full list of unique samples that are not sorted into groups, set the itrace option to
188 generate 'instruction' samples. The period option is also taken into account, so set it to 1
189 instruction unless you want to further downsample the already sampled SPE data:
191 perf report --itrace=i1i
193 Memory access details are also stored on the samples and this can be viewed with:
195 perf report --mem-mode
200 - "Cannot find PMU `arm_spe'. Missing kernel support?"
202 Module not built or loaded, KPTI not disabled (see above), or running on a VM
204 - "Arm SPE CONTEXT packets not found in the traces."
206 Root privilege is required to collect context packets. But these only increase the accuracy of
207 assigning PIDs to kernel samples. For userspace sampling this can be ignored.
209 - Excessively large perf.data file size
211 Increase sampling interval (see above)
217 linkperf:perf-record[1], linkperf:perf-script[1], linkperf:perf-report[1],
218 linkperf:perf-inject[1]