[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250116204225.GA7232@noisy.programming.kicks-ass.net>
Date: Thu, 16 Jan 2025 21:42:25 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: "Liang, Kan" <kan.liang@...ux.intel.com>
Cc: mingo@...hat.com, acme@...nel.org, namhyung@...nel.org,
irogers@...gle.com, adrian.hunter@...el.com,
linux-kernel@...r.kernel.org, linux-perf-users@...r.kernel.org,
ak@...ux.intel.com, eranian@...gle.com, dapeng1.mi@...ux.intel.com
Subject: Re: [PATCH V9 3/3] perf/x86/intel: Support PEBS counters snapshotting
On Thu, Jan 16, 2025 at 10:55:46AM -0500, Liang, Kan wrote:
> > Also, I think I found you another bug... Consider what happens to the
> > counter value when we reschedule a HES_STOPPED counter, then we skip
> > x86_pmu_start(RELOAD) on step2, which leave the counter value with
> > 'random' crap from whatever was there last.
> >
> > But meanwhile you do program PEBS to sample it. That will happily sample
> > this garbage.
> >
> > Hmm?
>
> I'm not quite sure I understand the issue.
>
> The HES_STOPPED counter should be a pre-existing counter. Just for some
> reason, it's stopped, right? So perf doesn't need to re-configure the
> PEBS__DATA_CFG, since the idx is not changed.
Suppose you have your group {A, B, C} and lets suppose A is the PEBS
event, further suppose that B is also a sampling event. Lets say they
get hardware counters 1,2 and 3 respectively.
Then lets say B gets throttled.
While it is throttled, we get a new event D scheduled, and D gets placed
on counter 2 -- where B lives, which gets moved over to counter 4.
Then our loops will update and remove B from 2, but because
throttled/HES_STOPPED it will not start it on counter 4.
Meanwhile, we do have the PEBS_DATA_CFG thing updated to sample counter
1,3 and 4.
PEBS assist happens, and samples the uninitialized counter 4.
We unthrottle B and program counter 4.
Powered by blists - more mailing lists