From: Frederic Weisbecker <fweisbec@gmail.com>
To: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: Hitoshi Mitake <mitake@dcl.info.waseda.ac.jp>,
Jason Baron <jbaron@redhat.com>,
Steven Rostedt <rostedt@goodmis.org>, Ingo Molnar <mingo@elte.hu>,
Peter Zijlstra <peterz@infradead.org>,
linux-kernel@vger.kernel.org, h.mitake@gmail.com,
Paul Mackerras <paulus@samba.org>,
Arnaldo Carvalho de Melo <acme@redhat.com>,
Jens Axboe <jens.axboe@oracle.com>
Subject: Re: [PATCH RFC 00/11] lock monitor: Separate features related to lock
Date: Fri, 19 Mar 2010 04:06:13 +0100 [thread overview]
Message-ID: <20100319030611.GE22095@nowhere> (raw)
In-Reply-To: <20100319024042.GB28941@Krystal>
On Thu, Mar 18, 2010 at 10:40:42PM -0400, Mathieu Desnoyers wrote:
> Well, the use-case that drove the asm goto implementation _is_ the tracepoints.
> ;)
>
> >
> > But, looking at __DO_TRACE:
> >
> > if (it_func) { \
> > do { \
> > ((void(*)(proto))(*it_func))(args); \
> > } while (*(++it_func)); \
> > }
> >
> > I would expect the compiler not to load the parameters in the stack
> > before first checking the branch.
>
> Note that you have to put that in its full context. It's a macro expanded within
> a static inline function. The initial parameters are passed to the static
> inline, not directly as "args" here. So parameters with side-effects have to be
> evaluated before their result can be passed to the static inline function, so in
> that sense their evaluation cannot be moved into the conditional branch.
Evaluation yeah, I agree. A function passed as an argument is
going to be evaluated indeed, or whatever thing that has a side effect.
But there is nothing here that need to setup the parameters to the stack
right before the true tracepoint call, not until we passed the branch check
once.
> > So, the fact that parameters are not loaded before we know we'll call
> > the tracepoint is something we already have or is it something that the jump
> > label brings in the package somehow?
>
> It's standard compiler optimization behavior.
Sure. My doubt is: currently with the upstream version, does the
compiler tend to load the parameters to the stack before the branch is
checked? Or is this a magic that jmp labels bring for whatever reason?
Thanks.
next prev parent reply other threads:[~2010-03-19 3:06 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-14 10:38 [PATCH RFC 00/11] lock monitor: Separate features related to lock Hitoshi Mitake
2010-03-14 10:38 ` [PATCH RFC 01/11] lock monitor: New subsystem for lock event hooking Hitoshi Mitake
2010-03-14 10:38 ` [PATCH RFC 02/11] Adopt lockdep to lock monitor Hitoshi Mitake
2010-03-14 10:38 ` [PATCH RFC 03/11] Adopt spinlock " Hitoshi Mitake
2010-03-14 10:38 ` [PATCH RFC 04/11] Adopt rwlock " Hitoshi Mitake
2010-03-14 10:38 ` [PATCH RFC 05/11] Adopt arch dependent rwsem " Hitoshi Mitake
2010-03-14 10:38 ` [PATCH RFC 06/11] Adopt rwsem of x86 " Hitoshi Mitake
2010-03-14 10:38 ` [PATCH RFC 07/11] Adopt the way of initializing semaphore " Hitoshi Mitake
2010-03-14 10:38 ` [PATCH RFC 08/11] Adopt mutex " Hitoshi Mitake
2010-03-14 10:38 ` [PATCH RFC 09/11] Adopt rcu_read_lock() " Hitoshi Mitake
2010-03-14 10:38 ` [PATCH RFC 10/11] Adopt kernel/sched.c " Hitoshi Mitake
2010-03-14 10:38 ` [PATCH RFC 11/11] Very dirty temporal solution for testing " Hitoshi Mitake
2010-03-14 18:13 ` [PATCH RFC 00/11] lock monitor: Separate features related to lock Peter Zijlstra
2010-03-17 1:32 ` Frederic Weisbecker
2010-03-17 7:30 ` Hitoshi Mitake
2010-03-17 15:39 ` Frederic Weisbecker
2010-03-18 5:49 ` Hitoshi Mitake
2010-03-18 20:30 ` Frederic Weisbecker
2010-03-20 5:51 ` Hitoshi Mitake
2010-03-23 15:45 ` Peter Zijlstra
2010-03-17 9:52 ` Ingo Molnar
2010-03-17 13:59 ` Jason Baron
2010-03-18 5:59 ` Hitoshi Mitake
2010-03-18 21:16 ` Frederic Weisbecker
2010-03-19 1:08 ` Mathieu Desnoyers
2010-03-19 1:23 ` Frederic Weisbecker
2010-03-19 1:36 ` Mathieu Desnoyers
2010-03-19 2:27 ` Frederic Weisbecker
2010-03-19 2:40 ` Mathieu Desnoyers
2010-03-19 3:06 ` Frederic Weisbecker [this message]
2010-03-19 12:56 ` Mathieu Desnoyers
2010-03-19 16:00 ` Jason Baron
2010-03-20 4:51 ` Frederic Weisbecker
2010-03-20 4:46 ` Frederic Weisbecker
2010-03-20 5:56 ` Hitoshi Mitake
2010-03-20 8:23 ` Hitoshi Mitake
2010-03-21 9:49 ` Hitoshi Mitake
2010-03-23 15:32 ` Peter Zijlstra
2010-04-04 7:56 ` Hitoshi Mitake
2010-03-17 1:47 ` Frederic Weisbecker
2010-03-17 7:33 ` Hitoshi Mitake
2010-03-17 9:50 ` Ingo Molnar
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=20100319030611.GE22095@nowhere \
--to=fweisbec@gmail.com \
--cc=acme@redhat.com \
--cc=h.mitake@gmail.com \
--cc=jbaron@redhat.com \
--cc=jens.axboe@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=mingo@elte.hu \
--cc=mitake@dcl.info.waseda.ac.jp \
--cc=paulus@samba.org \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.