[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1294249306.26623.33.camel@gandalf.stny.rr.com>
Date: Wed, 05 Jan 2011 12:41:46 -0500
From: Steven Rostedt <rostedt@...dmis.org>
To: Jason Baron <jbaron@...hat.com>
Cc: peterz@...radead.org, mathieu.desnoyers@...ymtl.ca, hpa@...or.com,
mingo@...e.hu, tglx@...utronix.de, andi@...stfloor.org,
roland@...hat.com, rth@...hat.com, masami.hiramatsu.pt@...achi.com,
fweisbec@...il.com, avi@...hat.com, davem@...emloft.net,
sam@...nborg.org, ddaney@...iumnetworks.com,
michael@...erman.id.au, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] jump label: introduce static_branch()
On Wed, 2011-01-05 at 10:43 -0500, Jason Baron wrote:
> Introduce:
>
> static __always_inline bool static_branch(struct jump_label_key *key)
>
> to replace the old JUMP_LABEL(key, label) macro.
>
> The new static_branch(), simplifies the usage of jump labels. Since,
> static_branch() returns a boolean, it can be used as part of an if()
> construct. It also, allows us to drop the 'label' argument from the
> prototype. Its probably best understood with an example, here is the part
> of the patch that converts the tracepoints to use unlikely_switch():
>
> --- a/include/linux/tracepoint.h
> +++ b/include/linux/tracepoint.h
> @@ -146,9 +146,7 @@ static inline void tracepoint_update_probe_range(struct tracepoint *begin,
> extern struct tracepoint __tracepoint_##name; \
> static inline void trace_##name(proto) \
> { \
> - JUMP_LABEL(&__tracepoint_##name.key, do_trace); \
> - return; \
> -do_trace: \
> + if (static_branch(&__tracepoint_##name.key)) \
> __DO_TRACE(&__tracepoint_##name, \
> TP_PROTO(data_proto), \
> TP_ARGS(data_args)); \
BTW, do not put real diffs in the change log. That is, remove the header
from it. This can confuse tools that pull in patches from mailing lists.
As this change will be done in the code itself.
Thanks,
-- Steve
>
>
> I analyzed the code produced by static_branch(), and it seems to be
> at least as good as the code generated by the JUMP_LABEL(). As a reminder,
> we get a single nop in the fastpath for -02. But will often times get
> a 'double jmp' in the -Os case. That is, 'jmp 0', followed by a jmp around
> the disabled code. We believe that future gcc tweaks to allow block
> re-ordering in the -Os, will solve the -Os case in the future.
>
> I also saw a 1-2% tbench throughput improvement when compiling with
> jump labels.
>
> This patch also addresses a build issue that Tetsuo Handa reported where
> gcc v3.3 currently chokes on compiling 'dynamic debug':
--
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