[PATCH 2/4] perf arm-spe: Downsample all sample types equally
Leo Yan
leo.yan at arm.com
Tue Sep 9 02:47:34 PDT 2025
On Mon, Sep 08, 2025 at 01:10:19PM +0100, James Clark wrote:
> The various sample types that are generated are based on the same SPE
> sample, just placed into different sample type bins. The same sample can
> be in multiple bins if it has flags set that cause it to be.
>
> Currently we're only applying the --itrace interval downsampling to the
> instruction bin, which means that the sample would appear in one bin but
> not another if it was skipped due to downsampling. I don't thing anyone
> would want or expect this, so make this behave consistently by applying
> the downsampling before generating any sample.
>
> You might argue that the "instructions" interval type doesn't make sense
> to apply to "memory" sample types because it would be skipping every n
> memory samples, rather than every n instructions. But the downsampling
> was already not an instruction interval even for the instruction
> samples. SPE has a hardware based sampling interval, and the instruction
> interval was just a convenient way to specify further downsampling. This
> is hinted at in the warning message shown for intervals greater than 1.
>
> This makes SPE diverge from trace technologies like Intel PT and Arm
> Coresight. In those cases instruction samples can be reduced but all
> branches are still emitted. This makes sense there, because branches
> form a complete execution history, and asking to skip branches every n
> instructions doesn't really make sense. But for SPE, as mentioned above,
> downsampling the instruction samples already wasn't consistent with
> trace technologies so we ended up with some middle ground that had no
> benefit. Now it's possible to reduce the volume of samples in all groups
> and samples won't be missing from one group but present in another.
>
> Signed-off-by: James Clark <james.clark at linaro.org>
The reason for unifying period for all samples is reasonable to me:
Reviewed-by: Leo Yan <leo.yan at arm.com>
More information about the linux-arm-kernel
mailing list