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

[Frederic Weisbecker <fweisbec@gmail.com>]

On Sat, Jul 25, 2009 at 06:22:52PM +0200, Peter Zijlstra wrote:
> On Sat, 2009-07-25 at 16:19 +0200, Frederic Weisbecker wrote:
> 
> > > Ah, but that is sub-optimal, perf counters doesn't actually change the
> > > state if both tasks have the same counter configuration. Yielding a
> > > great performance benefit on scheduling intensive workloads. Poking at
> > > these MSRs, esp. writing to them is very expensive.
> > 
> > 
> > Ah ok.
> > 
> >  
> > > So I would suggest not using that feature of the breakpoint API for the
> > > perf counter integration.
> > 
> > 
> > That would forbid some kinds of profiling (explanations below).
> > 
> > 
> > > > However, this patchset only deals with kernel breakpoint for now (wide
> > > > tracing).
> > > 
> > > Right, and that's all you would need for perf counter support, please
> > > don't use whatever task state handling you have in place.
> > 
> > 
> > I would actually propose to have a separate layer that manages
> > the hardware registers <-> per thread virtual registers handling
> > for things like breakpoint api and perfcounter.
> > 
> > I know a simple RR of registers is not that hard to write, but at
> > least that can allow simultaneous use of perfcounter and other users
> > of breakpoint API without having  two different versions of register
> > management.
> 
> I simply cannot see how you would be able to multiplex userspace/debug
> breakpoints. I'd utterly hate it if I'd missed a breakpoint simply
> because someone else also wanted to make use of it.


What I mean by multiplexing is that, say in x86, each task can have
4 breakpoints maximum. Once the task is scheduled out, its breakpoints
are saved and the hardware debug registers are used for the next task.
Once a task registers a breakpoint, it never looses it.

 
> I'd declare the system broken and useless.
> 
> Counters OTOH can be multiplexed because of their statistical nature,
> you can simply scale them back up based on their time share.
> 
> Therefore you'll have to deal with hard reservations anyway.
> 
> Also, you don't need to a-priory reserve all breakpoints, you'll simply
> need as many as the largest group (wrt breakpoints) has.

I still don't understand why it is needed to reserve breakpoints for
a group of monitored tasks. Once they have registered their breakpoints,
the number of necessary hardware registers for these will be available
every time the task is scheduled.

By nature, MAX_NR (4 in x86) breakpoints are available for every tasks, minus
the number of wide kernel breakpoints in use.

I don't see the need of a reservation here (which is already done by the API),
I feel a bit confused in this debate.