[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110316010304.GB7760@nowhere>
Date: Wed, 16 Mar 2011 02:03:06 +0100
From: Frederic Weisbecker <fweisbec@...il.com>
To: Arnaldo Carvalho de Melo <acme@...stprotocols.net>
Cc: LKML <linux-kernel@...r.kernel.org>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Paul Mackerras <paulus@...ba.org>,
Stephane Eranian <eranian@...gle.com>,
Steven Rostedt <rostedt@...dmis.org>,
Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
Thomas Gleixner <tglx@...utronix.de>,
Hitoshi Mitake <mitake@....info.waseda.ac.jp>
Subject: Re: [RFC PATCH 0/4] perf: Custom contexts
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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists