Re: [RFC PATCH 0/4] perf: Custom contexts

[Frederic Weisbecker <fweisbec@gmail.com>]

On Mon, Mar 14, 2011 at 08:02:11PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Mon, Mar 14, 2011 at 11:43:46PM +0100, Frederic Weisbecker escreveu:
> > On Mon, Mar 14, 2011 at 06:56:03PM -0300, Arnaldo Carvalho de Melo wrote:
> > > Em Mon, Mar 14, 2011 at 10:20:53PM +0100, Frederic Weisbecker escreveu:
> > > > On Mon, Mar 14, 2011 at 06:03:15PM -0300, Arnaldo Carvalho de Melo wrote:
> > > > > Em Mon, Mar 14, 2011 at 09:51:02PM +0100, Frederic Weisbecker escreveu:
> > > > > > On Mon, Mar 14, 2011 at 05:43:41PM -0300, Arnaldo Carvalho de Melo wrote:
> > > 
> > > > > But starter on a starter? Couldn't grok, could you provide an example?
> > > > 
> > > > I have no strong example in mind.
> > > > 
> > > > But one may want to count instructions when we are in an interrupt and
> > > > lock A is held.
> > > 
> > > Those would be and/or starter/stopper expressions, something like:
> > > 
> > > $ perf record -e instructions@(irq:irq_handler_entry(irq=eth0) && lock:lock_acquired(foo_lock))..irq:irq_handler_exit(\1) \
> > > 	      -e instructions \
> > > 	netperf
> > > 
> > > when all starters before the stopper are valid, we entered a range.
> > 
> > So, if we want to stop when lock is released, we do:
> > 
> > perf record -e instructions@(irq:irq_handler_entry(irq=eth0) && lock:lock_acquired(foo_lock))..lock:lock_release(foo_lock) && irq:irq_handler_exit(\1) \
> >              -e instructions \
> > 	netperf
> > 
> > Or || for stoppers like you do below? Hmm, I'm confused...
> > 
> > >  
> > > > Or count instruction when A and B are held.
> > > 
> > > Using wildcards that matches just the things we want to make it a bit
> > > more compact:
> > > 
> > > $ perf record -e inst*@(irq:*entry(irq=eth0) && lock:*acquired(A) && \
> > > 			lock:*acquired(B))..(lock:*release(A) || lock:*release(B)) \
> > > 	./my_workload
> > > 
> > > Parenthesis don't have to be used just for filters :) Just like in C,
> > > they can be used to express the list of parameters for a function or for
> > > expressions, etc.
> > 
> > The && make sense. But the || ?
> > 
> > What about:
> > 
> > -e inst*@(lock:*acquire(A)..lock:*release(A))@(lock:*acquire(B)..lock:*release(B))@(irq:*entry(irq=eth0)..irq:*exit(irq=eth0))
> > 
> > That looks to me less confusing.
> 
> Now it seems its me that needs to have some sleep :-) I find the above
> confusing, but I'm in a hurry right now, will try to comment more
> tomorrow.

Hehe :)

-e inst*@(lock:*acquire(A)..lock:*release(A))@(lock:*acquire(B)..lock:*release(B))

means we want to count instructions when we hold A and B, with A held
inside a section where we hold B.

Right?

But that's limited. We should express it that way:

	-e inst*@((lock:*acquire(B)..lock:*release(B) && (lock:*acquire(A)..lock:*release(A)))

Which means we first define a state where B is held. Inside that state we define
another one where A is held.

If we want to have an event always running, from the beginning, until we
acquire B:

	-e inst*@(..lock:*acquire(B))
or:
	-e inst*@..lock:*acquire(B)

If we want to only count once we hold B:

	-e inst*@lock:*acquire(B)..

If we want to count everywhere but when we hold B:

	-e inst*@(..lock:*acquire(B) && lock:*release(B)..)

This covers about everything. Now if in the future we want to support having
multiple starters or stoppers for a single target, in order to union custom
contexts, we can use the ||.

Like only count when we hold B or when we hold A:

	-e inst*@(lock:*acquire(A)..lock:*release(A) || lock:*acquire(B)..lock:*release(B))

Right?

  
> > > > Event range define a state, and anytime you need to profile/trace a
> > > > desired stacked state, starters on starters can be a good solution,
> > > > thus even a common practice.
> > > 
> > > See above, is that what you're thinking about?
> > 
> > I'm not sure. I can find the meaning of && in your expressions. But not
> > the meaning of ||. I lack some sleep though :)
> > 
> > But still, I'm all for trying to make a better and smarter way to
> > express these events, following your suggestions, but I'm not sure I have
> > the motivation to write a full parser capable of evaluating near C expressions.
> 
> See the other message, the start of it is there, thanks to Masami.

Indeed. I just had a look and it provides a basic parsing. Now it's tied to string
glob comparison and it needs to be generalized to support some custom set of
operation. Notwithstanding the final intepretation that is not trivial.

So that's a lot of work. I'd rather suggest to do this as a separate work. And
may be start with the raw --starter/--stopper things or alike to start. We can
still remove that, with the --filter thing, once we have the event comprehension
well settled.