Re: perf_disable()

[Frederic Weisbecker <fweisbec@gmail.com>]

On Fri, Jun 11, 2010 at 10:29:40PM +0200, Peter Zijlstra wrote:
> On Fri, 2010-06-11 at 19:17 +0200, Frederic Weisbecker wrote:
> > I suspect the problem is also on per context integrity. When you adjust
> > the period, enable or disable a counter, this counter becomes async with
> > the rest of the group or the rest of the counters in the same context, for
> > a small bunch of time.
> > 
> > The longer you run your events, the higher is going to be this jitter.
> > 
> > Take an example, when you adjust a period, you:
> > 
> > perf_disable()
> > perf_event_stop()
> > left_period = 0
> > perf_event_start()
> > perf_enable()
> > 
> > During all this time, the given event is paused, but the whole rest of
> > the events running on the cpu continue to count.
> > 
> > The problem is the same on context switch.
> > 
> > And I think this high resolution of synchronisation per context is
> > sensitive, especially with perf start kind of workflows.
> 
> I'm not sure what you're arguing, but the knife cuts on both sides, the
> above also stops counters that shouldn't be stopped..


Hmm, now that I look at it, x86_pmu_*able_all() isn't touching a
single register to *able everything at once, it's doing a loop
on every events.

Forget about what I said then.

 
> > > There is a fun little recursion issue with perf_adjust_period(), where
> > > if we fully removed perf_disable() we could end up calling pmu::stop()
> > > twice and such.
> > > 
> > > But aside from that it looks to me its mostly about optimizing hardware
> > > writes.
> > > 
> > > If nobody else known about/can find anything, I'm going to mostly remove
> > > perf_disable() for now and later think about how to optimize the
> > > hardware writes again.
> > 
> > 
> > Not sure that's a good idea IMHO.
> 
> Well, we need to do something, the current weak mess needs to go, and
> the alternative is basically a loop over all registerd pmus calling
> their respective pmu::disable_all, which is utter suckage, so removing
> as many of this as possible is a good thing.
> 
> We can always come up with some lazy mode later that tries to batch the
> hardware writes.


Right.