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

[Frederic Weisbecker <fweisbec@gmail.com>]

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
  manipulation.

- 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 :)

Thanks.