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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.