Re: [PATCH v2 03/13] perf/x86/amd: add AMD Fam19h Branch Sampling support
From: Peter Zijlstra
Date: Thu Nov 18 2021 - 07:21:25 EST
On Tue, Nov 16, 2021 at 11:23:39PM -0800, Stephane Eranian wrote:
> On Tue, Nov 16, 2021 at 12:29 AM Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:
> >
> > On Mon, Nov 15, 2021 at 11:48:01PM -0800, Stephane Eranian wrote:
> > > On Fri, Nov 12, 2021 at 8:02 AM Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:
> > > >
> > > > On Thu, Nov 11, 2021 at 12:44:05AM -0800, Stephane Eranian wrote:
> > > > > diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c
> > > > > index 38b2c779146f..28559557f966 100644
> > > > > --- a/arch/x86/events/core.c
> > > > > +++ b/arch/x86/events/core.c
> > > > > @@ -683,11 +683,16 @@ void x86_pmu_disable_all(void)
> > > > >
> > > > > if (!test_bit(idx, cpuc->active_mask))
> > > > > continue;
> > > > > +
> > > > > + if (is_amd_brs(hwc))
> > > > > + amd_brs_disable();
> > > > > +
> > > > > rdmsrl(x86_pmu_config_addr(idx), val);
> > > > > if (!(val & ARCH_PERFMON_EVENTSEL_ENABLE))
> > > > > continue;
> > > > > val &= ~ARCH_PERFMON_EVENTSEL_ENABLE;
> > > > > wrmsrl(x86_pmu_config_addr(idx), val);
> > > > > +
> > > > > if (is_counter_pair(hwc))
> > > > > wrmsrl(x86_pmu_config_addr(idx + 1), 0);
> > > > > }
> > > >
> > > > Please, stick that in amd_pmu_disable_all().
> > >
> > >
> > > If I do that, I need to add a for_each_counter() loop to
> > > amd_pmu_disable_all() but it does not have one call systematically.
> > > If you are okay with it, then I am fine as well.
> >
> > Why ? There is only one BRS you can disable it first, and then do the
> > loop. Same on the enable_all side, enable it once, not per event.
> > ->add/->del can keep a per-event count for sharing purposes, but you
> > don't need that for {en,dis}able_all, right?
>
> Ok, I made the changes you suggested. It looks closer to the way LBR is handled.
> However, this means that there is no path by which you can get to
> amd_pmu_disable_event()
> without having gone through amd_pmu_disable_all(). Is that always the
> case? And same thing
> on the enable side.
So that's true for ->add() and ->del(), those cannot be called without
being wrapped in ->pmu_disable(), ->pmu_enable().
There is however the ->stop() and ->start() usage for throttling, which
can stop an individual event (while leaving the event scheduled on the
PMU). Now, I think the ->stop() gets called with the PMU enabled, but
the ->start() is with it disabled again.
The ramification would be that we'd stop the event, but leave BRS
enabled for a throttled event. Which should be harmless, no?