Re: [RFC][PATCH] perf, intel: Don't touch MSR_IA32_DEBUGCTLMSR fromNMI context

[Peter Zijlstra]

On Wed, 2012-09-12 at 20:00 +0200, Stephane Eranian wrote:
> On Wed, Sep 12, 2012 at 7:45 PM, Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:
> > On Wed, 2012-09-12 at 19:37 +0200, Peter Zijlstra wrote:
> >> Ah, so I do think EIO will re-enable LBR,
> >
> > OK, it does not, but the:
> >
> >>  also the handler is wrapped in
> >> x86_pmu::{dis,en}able_all() which does end up calling
> >> intel_pmu_lbr_{dis,en}able_all().
> >
> > Thing does the re-enable for us,
> >
> 
> >>  However that leaves the MSR in the
> >> exact same state on exit as it was on enter, so that's not a problem for
> >> the: read-modify-write change.
> >
> > in a safe way.
> Well, I think it does even when we have to stop events (x86_pmu_stop)
> because the buffer is full. Looks like we always re-enable lbr.

How so, without the proposed patch, the intel_pmu_disable_event() can do
intel_pmu_lbr_disable() which decrements cpuc->lbr_users, so the final
intel_pmu_enable_all()->intel_pmu_lbr_enable_all() will be a NOP,
leaving LBR disabled, where we entered the NMI with LBR enabled.

>  So looks like the handler is a wash for debugctl.

As for BTS, it looks like we don't throttle the thing at all, so we
shouldn't ever get to the asymmetric thing, right?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/