On Wed, 19 Feb 2014, Peter Zijlstra wrote: > So when we add a new event (or more) we compute a mapping from event to > counter. Then we disable all (pre existing) events that moved to a new > location, then we enable all events (insert HES_ARCH) that were running > but got relocated and the new events. > > Of course the code is horrible, but I think the above is what it does.
The code is a pain, with all of the various ctx types, and the nested calls to perf_pmu_enable/perf_pmu_disable in particular. So I've hacked the code so that it shows the last location where hwc->state was cleared for an event (i.e., where it was last enabled). The NMI counter event was enabled in _perf_install_in_context (presumably at creation time) and as far as I can tell never disabled. Then when x86_pmu_enable/x86_pmu_start gets called at the end of _perf_event_context_sched_in() it is sad because the NMI counter event is not disabled. So where would the NMI counter event get disabled? Would it never get disabled, just because it's always running and always gets the same fixed slot? Why isn't this a problem all the time, not just with corner cases? Is somehow n_added getting confused? Vince -- 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/
