Re: [PATCH 1/5] perf: Provide a proper stop action for softwareevents

From: Frederic Weisbecker
Date: Sat Jun 12 2010 - 12:26:01 EST

On Sat, Jun 12, 2010 at 11:43:11AM +0200, Peter Zijlstra wrote:
> On Sat, 2010-06-12 at 09:34 +0200, Frederic Weisbecker wrote:
> > In order to introduce new context exclusions, software events will
> > have to eventually stop when needed. We'll want perf_event_stop() to
> > act on every events.
> >
> > To achieve this, remove the stub stop/start pmu callbacks of software
> > and tracepoint events that fixed a race in perf_adjust_period, and do
> > an explicit check to only reset the hardware event using the
> > start/stop callbacks.
> I really object to this,. its just too ugly to live.

Several propositions of alternatives then, please tell me if one
looks more palatable to you:

- Having an argument on ->stop() and ->start() callback which
would be reset_period. If reset_period is true, then the event
knows the goal is to reprogram the interrupt.

FWIW, that's my prefered solution, software pmus can just check
this and return immediately. This avoids all the race between
concurrent stat and stop plus the wasteful/useless hlist

- Having a nesting level control on stop and start, so that
we only call stop/start on nesting level 0. That solves the race.

- Having a flag in the pmu that tells if it wants to reprogram
on period reset. Then we know if we need the start/stop against
this flag. I just propose this one for the fun, I already
know it sucks :)


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at