[RFC PATCH v2 0/4] A mechanism for efficient support for per-function metrics
Ben Gainey
Ben.Gainey at arm.com
Fri Apr 26 04:11:32 PDT 2024
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
More information about the linux-arm-kernel
mailing list