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

[Frederic Weisbecker]

On Tue, Mar 15, 2011 at 04:24:22PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Tue, Mar 15, 2011 at 07:58:16PM +0100, Frederic Weisbecker escreveu:
> > If we want to count everywhere but when we hold B:
> > 
> > 	-e inst*@(..lock:*acquire(B) && lock:*release(B)..)
> 
> Makes sense but looks confusing at first sight, how to translate that to
> events starter/stoppers?
> 
> its an event: instructions, it starts in what state? Enabled, i.e. the
> first part of the expression has precedence: ..lock:*acquire(B), then,
> after it is disabled, because we acquired B, the second part gets armed,
> i.e. when the release(B) event takes place, the first part gets armed
> again.
> 
> That is why I felt '&&' to be confusing, its not that both are in
> effect, its that one is only armed when the previous was disarmed.
> 
> Perhaps we could find some other operator that was more natural, or just
> agree that && in this context works this way, almost like what we do in
> shell scripting with && and || (the cycle to rearm the first range after
> the last one is disarmed is the part that doesn't matches the shell
> use).

Doh you're right. && would have two meaning.
No we should probably keep  a && b  has a meaning of we are
in the range a AND in the range b. Both at the same time, with
a evaluated first and then b. We also need to ensure than
a && b  doesn't mean the same than  b && a. You're right, perhaps
we need another operator to expression inclusion, or we need to
assume that specific meaning of &&.

For what I wanted to express in the example above, || seem be the
right choice: -e inst*@(..lock:*acquire(B) || lock:*release(B)..)

So || would mean union and && would mean inclusion.

> 
> Also:
> 
>  	-e inst*@(lock:*release(B)..lock:*acquire(B))
> 
> Wouldn't be simpler? Not equivalent tho if one is interested in
> everything that happens till the first time the lock is acquired in some
> specific thread that is started from the tool, etc.

Yep, they are not the same.

>  
> > 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?
> 
> Yeah, this one is natural at first sight. As is:
> 
>  	-e (inst*,cycles,dTLB*misses)@(lock:*acquire(A)..lock:*release(A) || lock:*acquire(B)..lock:*release(B))
> 
> I.e. we're expressing an evlist (list of event selectors) to be counted
> when the 'at' expression allows.

Indeed, looks nice.
--
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/