Re: [RFC][PATCH 5/5] perfcounter: Add support for kernel hardware breakpoints

[Peter Zijlstra <a.p.zijlstra@chello.nl>]

On Wed, 2009-07-29 at 02:36 +0200, Frederic Weisbecker wrote:
> On Tue, Jul 28, 2009 at 09:24:37AM +0200, Peter Zijlstra wrote:
> > On Tue, 2009-07-28 at 03:03 +0200, Frederic Weisbecker wrote:
> > > > Thirdly, we can multiplex perf counters beyond their hardware maximum,
> > > > something you simply cannot do for a debug interface.
> > > 
> > > 
> > > Again, I'm stuck in what you mean by multiplexing here :-)
> > 
> > If you'd create say 16 breakpoint counters, we'd RR them over the 4
> > available hardware breakpoints (or less when others are taken by someone
> > else).
> > 
> > Since its all statistics anyway, we can simply scale the event counts up
> > by the time-share they received.
> >
> 
> Aah, ok I understand now.
> But I fear it may kill the accuracy of the breakpoints statistics.
> It's fine for a theoretical linear rate of breakpoint events.
> But what happens if we are profiling something much more unstable
> with a rain of hits in a small window of memory between large timeframes?
> If we have a breakpoint inside this window of memory and this breakpoint
> is not plugged, waiting for its turn in the RR, we loose this rain of events.

You don't have to overload the breakpoint set, but we will if you create
more than there are hardware resources available.

If the RR period is independent of the application and significantly
shorter than the sample duration, statistics will be usable.

Sure, they'll not be perfect, but we can improve our confidence interval
by running longer. At some point it really doesn't matter anymore.

Take your example, of small bursts of events, due to the first
assumption - the RR period being independent of the application - we're
bound to see those busts in a proportional number of sample windows.

If the full sample duration is in the same order of the RR period, then
yes, you'll have a fair chance of missing the burst -- don't do that
then :-)

If you know you'll be running very very short, use attr.pinned, to
request a counter that'll not be multiplexed.