lkml.org 
[lkml]   [2014]   [Feb]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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



\
 
 \ /
  Last update: 2014-02-20 00:21    [W:0.067 / U:1.140 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site