From: Ben Gainey <Ben.Gainey@arm.com>
To: "ak@linux.intel.com" <ak@linux.intel.com>
Cc: "alexander.shishkin@linux.intel.com"
<alexander.shishkin@linux.intel.com>,
"linux-perf-users@vger.kernel.org"
<linux-perf-users@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"peterz@infradead.org" <peterz@infradead.org>,
Mark Rutland <Mark.Rutland@arm.com>,
"mingo@redhat.com" <mingo@redhat.com>,
James Clark <James.Clark@arm.com>,
"acme@kernel.org" <acme@kernel.org>,
"namhyung@kernel.org" <namhyung@kernel.org>,
"jolsa@kernel.org" <jolsa@kernel.org>,
"will@kernel.org" <will@kernel.org>,
"irogers@google.com" <irogers@google.com>,
"adrian.hunter@intel.com" <adrian.hunter@intel.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [RFC PATCH v2 0/4] A mechanism for efficient support for per-function metrics
Date: Fri, 26 Apr 2024 11:11:32 +0000 [thread overview]
Message-ID: <b0580124d8916d523afb98979a24f8108b0e700a.camel@arm.com> (raw)
In-Reply-To: <ZifW8rZk41t4ukIV@tassilo>
On Tue, 2024-04-23 at 08:42 -0700, Andi Kleen wrote:
> > Cursory testing on a Xeon(R) W-2145 with a 300 *instruction* sample
> > window (with and without the patch) suggests this approach would
> > work
> > for some counters. Calculating branch miss rates for example
> > appears to
> > be correct when used with the instruction counter as the sampling
> > event,
> > or at least this approach correctly identifies which functions in
> > the
> > test benchmark are prone to poor predictability. On the other hand
> > the
> > combination cycle and instructions counter does not appear to
> > sample
> > correctly as a pair. With something like
> >
> > perf record -e '{cycles/period=999700,alt-
> > period=300/,instructions}:uS' ... benchmark
> >
> > I often see very large CPI, the same affect is observed without the
> > patch enabled. No idea whats going on there, so any insight
> > welcome...
>
> My guess would be that the PMI handler cleared L1 and there are
> stalls
> reloading the working set. You can check L1 miss events to confirm.
> Unfortunately with the period change it cannot use multi-record
> PEBS which would avoid the need for a PMI.
>
> -Andi
Hi Andi,
Spent a bit of time looking at this.
Comparing the L1 counters against the values from 'perf stat' doesn't
appear to show some obvious cause.
I think this is just a quirk specific to using the cycle counter as the
sampling event, and is not related to the alt-period, as the affect is
present even on an unpatched kernel.
There appears to be some non-linear increase in CPI (over the sample
data as a whole) for the smallest values of period, e.g. for
period=100, CPI=~450; perf stat says it should be ~2.5. Manual
inspection of the raw data with:
perf script -F event,period -i perf.data.100
Shows repeating pattern along the lines of:
cycles=450
instructions=1
...
The affect quickly decreases as the period increases, with period=750,
the CPI is <2x (vs perf stat).
When the events are swapped so that the sampling event is
`instructions` rather than `cycles`, the affect is very much
diminished/gone; at P=100 is see about 3.5x overhead (vs perf stat),
and at P=500 the overhead is about 1.5x.
When alt-period is used such that "period=$((1000000-$P)),alt-
period=$P", the affect is unchanged.
Regards
Ben
prev parent reply other threads:[~2024-04-26 11:11 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-22 10:49 [RFC PATCH v2 0/4] A mechanism for efficient support for per-function metrics Ben Gainey
2024-04-22 10:49 ` [RFC PATCH v2 1/4] perf: Allow periodic events to alternate between two sample periods Ben Gainey
2024-04-22 10:49 ` [RFC PATCH v2 2/4] perf: Allow adding fixed random jitter to the alternate sampling period Ben Gainey
2024-04-22 13:08 ` James Clark
2024-04-22 14:40 ` Ben Gainey
2024-04-23 9:55 ` James Clark
2024-04-22 10:49 ` [RFC PATCH v2 3/4] tools/perf: Modify event parser to support alt-period term Ben Gainey
2024-04-22 10:49 ` [RFC PATCH v2 4/4] tools/perf: Modify event parser to support alt-period-jitter term Ben Gainey
2024-04-23 15:42 ` [RFC PATCH v2 0/4] A mechanism for efficient support for per-function metrics Andi Kleen
2024-04-26 11:11 ` Ben Gainey [this message]
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=b0580124d8916d523afb98979a24f8108b0e700a.camel@arm.com \
--to=ben.gainey@arm.com \
--cc=James.Clark@arm.com \
--cc=Mark.Rutland@arm.com \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=ak@linux.intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=irogers@google.com \
--cc=jolsa@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).