tools/perf/Documentation/perf-arm-spe.txt
Source file repositories/reference/linux-study-clean/tools/perf/Documentation/perf-arm-spe.txt
File Facts
- System
- Linux kernel
- Corpus path
tools/perf/Documentation/perf-arm-spe.txt- Extension
.txt- Size
- 15154 bytes
- Lines
- 346
- Domain
- Support Tooling And Documentation
- Bucket
- tools
- Inferred role
- Support Tooling And Documentation: documentation
- Status
- atlas-only
Why This File Exists
Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
- Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
- Touches IRQ or DMA behavior; this matters for the representative real-device path.
Dependency Surface
- No C-style include directives detected by the generator.
Detected Declarations
- No top-level syscall, struct, function, initcall, or export declaration detected by the generator.
Annotated Snippet
perf-arm-spe(1)
================
NAME
----
perf-arm-spe - Support for Arm Statistical Profiling Extension within Perf tools
SYNOPSIS
--------
[verse]
'perf record' -e arm_spe//
DESCRIPTION
-----------
The SPE (Statistical Profiling Extension) feature provides accurate attribution of latencies and
events down to individual instructions. Rather than being interrupt-driven, it picks an
instruction to sample and then captures data for it during execution. Data includes execution time
in cycles. For loads and stores it also includes data address, cache miss events, and data origin.
The sampling has 5 stages:
1. Choose an operation
2. Collect data about the operation
3. Optionally discard the record based on a filter
4. Write the record to memory
5. Interrupt when the buffer is full
Choose an operation
~~~~~~~~~~~~~~~~~~~
This is chosen from a sample population, for SPE this is an IMPLEMENTATION DEFINED choice of all
architectural instructions or all micro-ops. Sampling happens at a programmable interval. The
architecture provides a mechanism for the SPE driver to infer the minimum interval at which it should
sample. This minimum interval is used by the driver if no interval is specified. A pseudo-random
perturbation is also added to the sampling interval by default.
Collect data about the operation
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Program counter, PMU events, timings and data addresses related to the operation are recorded.
Sampling ensures there is only one sampled operation is in flight.
Optionally discard the record based on a filter
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Based on programmable criteria, choose whether to keep the record or discard it. If the record is
discarded then the flow stops here for this sample.
Write the record to memory
~~~~~~~~~~~~~~~~~~~~~~~~~~
The record is appended to a memory buffer
Interrupt when the buffer is full
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
When the buffer fills, an interrupt is sent and the driver signals Perf to collect the records.
Perf saves the raw data in the perf.data file.
Opening the file
----------------
Up until this point no decoding of the SPE data was done by either the kernel or Perf. Only when the
recorded file is opened with 'perf report' or 'perf script' does the decoding happen. When decoding
the data, Perf generates "synthetic samples" as if these were generated at the time of the
recording. These samples are the same as if normal sampling was done by Perf without using SPE,
although they may have more attributes associated with them. For example a normal sample may have
just the instruction pointer, but an SPE sample can have data addresses and latency attributes.
Annotation
- Atlas domain: Support Tooling And Documentation / tools.
- Implementation status: atlas-only.
- IRQ or DMA behavior appears here, which is relevant to the selected PCIe/NVMe device path.
Implementation Notes
- This generated page is the file-by-file coverage layer; curated subsystem chapters should link here when they synthesize a multi-file control flow.
- Core OS pages should be promoted from atlas-only to deep-reviewed when they explain data structures, invariants, locking, lifecycle, and C implementation snippets.
- Driver-family pages are intentionally pattern-oriented unless they are part of the selected PCIe/NVMe representative device path.