On Thu, Jun 11, 2015 at 03:13:57PM +0300, Alexander Shishkin wrote: > @@ -1426,7 +1426,23 @@ perf_event_nmi_handler(unsigned int cmd, struct > pt_regs *regs) > u64 finish_clock; > int ret; > > - if (!atomic_read(&active_events)) > + /* > + * Intel PT is a separate PMUs, it doesn't increment active_events > + * nor does it use resources associated with it, such as DS area. > + * However, it still uses the same PMI handler, so here we need > + * to make sure to call it *also* if any PT events are present. > + * > + * BTS events currently increment active_events implicitly through > + * x86_reserve_hardware(), where it acts as DS area reference > + * counter, so no need to check x86_lbr_exclusive_bts counter here; > + * otherwise we'd have to do the same for BTS. > + * > + * Theoretically, they could be made into separate PMI handlers, but > + * that can create additional challenges as PT uses the same PMI status > + * register as x86_pmu. > + */ > + if (!atomic_read(&active_events) && > + !atomic_read(&x86_pmu.lbr_exclusive[x86_lbr_exclusive_pt])) > return NMI_DONE; >
Urgh, sad. That's two cache misses instead of one. Cant we somehow keep that a single value to read? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
