[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.10.1402191727420.23543@vincent-weaver-1.um.maine.edu>
Date: Wed, 19 Feb 2014 17:34:49 -0500 (EST)
From: Vince Weaver <vincent.weaver@...ne.edu>
To: Peter Zijlstra <peterz@...radead.org>
cc: Dave Jones <davej@...hat.com>,
Linux Kernel <linux-kernel@...r.kernel.org>,
Ingo Molnar <mingo@...hat.com>,
Paul Mackerras <paulus@...ba.org>
Subject: Re: x86_pmu_start WARN_ON.
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 majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists