From: Leo Yan <leo.yan@arm.com>
To: James Clark <james.clark@linaro.org>
Cc: John Garry <john.g.garry@oracle.com>,
Will Deacon <will@kernel.org>, Mike Leach <mike.leach@linaro.org>,
Leo Yan <leo.yan@linux.dev>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Namhyung Kim <namhyung@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Jiri Olsa <jolsa@kernel.org>, Ian Rogers <irogers@google.com>,
Adrian Hunter <adrian.hunter@intel.com>,
George Wort <George.Wort@arm.com>,
Graham Woodward <Graham.Woodward@arm.com>,
Ben Gainey <Ben.Gainey@arm.com>,
Michael Williams <Michael.Williams@arm.com>,
linux-arm-kernel@lists.infradead.org,
linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/4] perf arm-spe: Downsample all sample types equally
Date: Tue, 9 Sep 2025 10:47:34 +0100 [thread overview]
Message-ID: <20250909094734.GA12516@e132581.arm.com> (raw)
In-Reply-To: <20250908-james-perf-spe-period-v1-2-7ccd805af461@linaro.org>
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@linaro.org>
The reason for unifying period for all samples is reasonable to me:
Reviewed-by: Leo Yan <leo.yan@arm.com>
next prev parent reply other threads:[~2025-09-09 17:15 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-08 12:10 [PATCH 0/4] perf arm-spe: Improve --itrace options James Clark
2025-09-08 12:10 ` [PATCH 1/4] perf arm-spe: Show instruction sample types by default James Clark
2025-09-08 12:10 ` [PATCH 2/4] perf arm-spe: Downsample all sample types equally James Clark
2025-09-09 9:47 ` Leo Yan [this message]
2025-09-08 12:10 ` [PATCH 3/4] perf arm-spe: Display --itrace period warnings for all sample types James Clark
2025-09-08 12:10 ` [PATCH 4/4] perf docs: Update SPE doc to include default instructions group James Clark
2025-09-08 21:16 ` [PATCH 0/4] perf arm-spe: Improve --itrace options Arnaldo Carvalho de Melo
2025-09-09 9:51 ` James Clark
2025-09-09 12:21 ` James Clark
2025-09-09 10:13 ` Leo Yan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250909094734.GA12516@e132581.arm.com \
--to=leo.yan@arm.com \
--cc=Ben.Gainey@arm.com \
--cc=George.Wort@arm.com \
--cc=Graham.Woodward@arm.com \
--cc=Michael.Williams@arm.com \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=irogers@google.com \
--cc=james.clark@linaro.org \
--cc=john.g.garry@oracle.com \
--cc=jolsa@kernel.org \
--cc=leo.yan@linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mike.leach@linaro.org \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=peterz@infradead.org \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox