On Wed, 2012-09-12 at 20:00 +0200, Stephane Eranian wrote: > On Wed, Sep 12, 2012 at 7:45 PM, Peter Zijlstra <[email protected]> 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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
