From: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
To: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>,
LKML <linux-kernel@vger.kernel.org>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
Paul Mackerras <paulus@samba.org>,
Stephane Eranian <eranian@google.com>,
Steven Rostedt <rostedt@goodmis.org>,
Thomas Gleixner <tglx@linutronix.de>,
Hitoshi Mitake <mitake@dcl.info.waseda.ac.jp>,
"2nddept-manager@sdl.hitachi.co.jp"
<2nddept-manager@sdl.hitachi.co.jp>
Subject: Re: [RFC PATCH 0/4] perf: Custom contexts
Date: Thu, 17 Mar 2011 00:47:01 +0900 [thread overview]
Message-ID: <4D80DB75.6060408@hitachi.com> (raw)
In-Reply-To: <20110316010304.GB7760@nowhere>
(2011/03/16 10:03), Frederic Weisbecker wrote:
> 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.
Hmm, would we really need that kind of complex rules?
It seems that we only need union case. If so, I'd suggest
you to use ',' to express that, instead of ||.
-e inst*@(..lock:*acquire(B),lock:*release(B)..)
Thank you,
--
Masami HIRAMATSU
2nd Dept. Linux Technology Center
Hitachi, Ltd., Systems Development Laboratory
E-mail: masami.hiramatsu.pt@hitachi.com
next prev parent reply other threads:[~2011-03-16 15:47 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-14 19:17 [RFC PATCH 0/4] perf: Custom contexts Frederic Weisbecker
2011-03-14 19:18 ` [RFC PATCH 1/4] perf: Starter and stopper events Frederic Weisbecker
2011-03-15 14:36 ` Lin Ming
2011-03-15 17:54 ` Frederic Weisbecker
2011-03-16 14:21 ` Frederic Weisbecker
2011-03-14 19:18 ` [RFC PATCH 3/4] perf: Support for starter and stopper in tools Frederic Weisbecker
2011-03-14 19:18 ` [RFC PATCH 4/4] perf: New --enable-on-starter option Frederic Weisbecker
2011-03-14 20:43 ` [RFC PATCH 0/4] perf: Custom contexts Arnaldo Carvalho de Melo
2011-03-14 20:51 ` Frederic Weisbecker
2011-03-14 21:03 ` Arnaldo Carvalho de Melo
2011-03-14 21:20 ` Frederic Weisbecker
2011-03-14 21:56 ` Arnaldo Carvalho de Melo
2011-03-14 22:19 ` Arnaldo Carvalho de Melo
2011-03-14 22:43 ` Frederic Weisbecker
2011-03-14 23:02 ` Arnaldo Carvalho de Melo
2011-03-15 18:58 ` Frederic Weisbecker
2011-03-15 19:24 ` Arnaldo Carvalho de Melo
2011-03-16 1:03 ` Frederic Weisbecker
2011-03-16 15:47 ` Masami Hiramatsu [this message]
2011-03-16 17:53 ` Arnaldo Carvalho de Melo
2011-03-16 18:02 ` Peter Zijlstra
2011-03-15 22:32 ` Peter Zijlstra
2011-03-16 13:53 ` Frederic Weisbecker
2011-03-16 13:56 ` Peter Zijlstra
2011-03-16 14:02 ` Frederic Weisbecker
2011-03-16 14:31 ` Peter Zijlstra
2011-03-25 14:47 ` Frederic Weisbecker
2011-03-25 15:03 ` Peter Zijlstra
2011-04-13 14:27 ` Frederic Weisbecker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4D80DB75.6060408@hitachi.com \
--to=masami.hiramatsu.pt@hitachi.com \
--cc=2nddept-manager@sdl.hitachi.co.jp \
--cc=a.p.zijlstra@chello.nl \
--cc=acme@ghostprotocols.net \
--cc=eranian@google.com \
--cc=fweisbec@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mitake@dcl.info.waseda.ac.jp \
--cc=paulus@samba.org \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox