Re: [PATCH] perf lock: clean the options for perf record

[Frederic Weisbecker <fweisbec@gmail.com>]

On Fri, Mar 04, 2011 at 02:58:19PM +0100, Peter Zijlstra wrote:
> On Fri, 2011-03-04 at 14:56 +0100, Frederic Weisbecker wrote:
> > lockstat is a global measurement since the boot.
> 
> You can reset lockstat at any given time.

Event though, that's still a global profiling. You can't have a per
process or thread granularity.

Or even more precise context for some future feature in perf that
I have in mind and would like to implement soon, like counting/sampling
an event only between two others. More exactly having two lists for
each event:

* activate
* deactivate

Those on the first list activate the target event when they overflow. (->start() )
Those on the second list deactivate .... (->stop() )

With events in activate and deactivate in the same context than the target,
locking and permissions should be kept simple. Locking especially shouldn't be
needed in the fast path. Then if that's needed we could think about a cross
context things later.

Plus an attr->start_state that decides if the first ->add() made is made
with PERF_EF_STAT or not. (We then need to keep track of some activated/deactivated
state across schedules).

That's in fact the exclude_irq and exclude_softirq idea extended to any kind
of existing event.