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

From: Frederic Weisbecker
Date: Fri Mar 04 2011 - 09:21:29 EST


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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/