lkml.org 
[lkml]   [2012]   [Sep]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RFC][PATCH] perf, intel: Don't touch MSR_IA32_DEBUGCTLMSR from NMI context
From
Date
On Wed, 2012-09-12 at 20:00 +0200, Stephane Eranian wrote:
> On Wed, Sep 12, 2012 at 7:45 PM, Peter Zijlstra <peterz@infradead.org> 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?


\
 
 \ /
  Last update: 2012-09-12 21:01    [W:0.060 / U:0.180 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site