From: Steven Rostedt <rostedt@goodmis.org>
To: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Cc: Jason Baron <jbaron@redhat.com>,
peterz@infradead.org, hpa@zytor.com, mingo@elte.hu,
tglx@linutronix.de, andi@firstfloor.org, roland@redhat.com,
rth@redhat.com, masami.hiramatsu.pt@hitachi.com,
fweisbec@gmail.com, avi@redhat.com, davem@davemloft.net,
sam@ravnborg.org, ddaney@caviumnetworks.com,
michael@ellerman.id.au, linux-kernel@vger.kernel.org
Subject: Re: [PATCH/RFC 0/2] jump label: simplify API
Date: Thu, 16 Dec 2010 15:18:23 -0500 [thread overview]
Message-ID: <1292530703.22905.3.camel@gandalf.stny.rr.com> (raw)
In-Reply-To: <20101216192241.GA8239@Krystal>
On Thu, 2010-12-16 at 14:22 -0500, Mathieu Desnoyers wrote:
> * Jason Baron (jbaron@redhat.com) wrote:
> > Hi,
> >
> > The first patch uses the storage space of the jump label key address
> > as a pointer into the update table. In this way, we can find all
> > the addresses that need to be updated without hashing.
> >
> > The second patch introduces:
> >
> > static __always_inline bool unlikely_switch(struct jump_label_key *key);
> >
> > instead of the old JUMP_LABEL(key, label) macro.
> >
> > In this way, jump labels become really easy to use:
> >
> > Define:
> >
> > struct jump_label_key jump_key;
> >
> > Can be used as:
> >
> > if (unlikely_switch(&jump_key))
> > do unlikely code
>
> Ah, yes, that's an improvement!
>
> I'm just wondering about the terminology here. Isn't that more a
> "branch" than a "switch" ?
>
> I'm concerned about the fact that if we ever want to use the asm goto
> ability to jump to multiple targets (which is closer to a statically
> computed switch than a branch), we might want to reserve "switch" name
> for that rather than the branch.
Good point.
>
> I wonder if the "if (unlikely_switch(&jump_key))" you propose above is
> the right thing to do. Why does the unlikely_ have to be included in the
> name ? Maybe there is a good reason for it, but it would be nice to have
> it spelled out. We might consider:
>
> if (unlikely(static_branch(&jump_key)))
> ...
>
> instead.
Hmm, I see your point here too.
> For the switch statement, from the top of my head the idea would be to
> get something close to the following:
>
> static __always_inline
> int static_switch_{3,4,5,6...}(struct jump_label_key *key);
>
> e.g.:
>
> static __always_inline
> int static_switch_3(struct jump_label_key *key)
> {
> asm goto("1:"
> JUMP_LABEL_INITIAL_NOP
> ".pushsection __switch_table_3, \"a\" \n\t"
> _ASM_PTR "%c0, 1b, %l[l_1], %l[l_2] \n\t"
> ".popsection \n\t"
> : : "i" (key) : : l_1, l_2 );
> return 0;
> l_1:
> return 1;
> l_2:
> return 2;
> }
>
> switch(static_switch_3(&switch_key)) {
> case 0: .....
> break;
> case 1: .....
> break;
> case 2: .....
> break;
> }
>
> (I have not tried to give that to gcc 4.5.x to see how the resulting
> assembly looks like. It would be interesting to see if it handles this
> case well)
Something to think about later (when we need such a thing). But I do
agree, perhaps calling it static_branch() instead, is a better idea.
-- Steve
prev parent reply other threads:[~2010-12-16 20:18 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-16 18:25 Jason Baron
2010-12-16 18:25 ` [PATCH/RFC 1/2] jump label: make enable/disable o(1) Jason Baron
2010-12-16 19:10 ` Peter Zijlstra
2010-12-16 19:23 ` Jason Baron
2010-12-16 19:33 ` Peter Zijlstra
2010-12-16 19:36 ` Jason Baron
2010-12-16 19:41 ` Peter Zijlstra
2010-12-16 19:48 ` Jason Baron
2010-12-16 20:09 ` Steven Rostedt
2010-12-16 20:36 ` Mathieu Desnoyers
2010-12-16 20:43 ` Peter Zijlstra
2010-12-16 20:50 ` Mathieu Desnoyers
2010-12-16 20:56 ` Peter Zijlstra
2010-12-17 20:07 ` Jason Baron
2010-12-17 20:51 ` David Daney
2010-12-17 21:12 ` Steven Rostedt
2010-12-17 21:32 ` Jason Baron
2010-12-16 20:45 ` Mathieu Desnoyers
2010-12-16 18:25 ` [PATCH/RFC 2/2] jump label: introduce unlikely_switch() Jason Baron
2010-12-16 19:22 ` [PATCH/RFC 0/2] jump label: simplify API Mathieu Desnoyers
2010-12-16 20:18 ` Steven Rostedt [this message]
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=1292530703.22905.3.camel@gandalf.stny.rr.com \
--to=rostedt@goodmis.org \
--cc=andi@firstfloor.org \
--cc=avi@redhat.com \
--cc=davem@davemloft.net \
--cc=ddaney@caviumnetworks.com \
--cc=fweisbec@gmail.com \
--cc=hpa@zytor.com \
--cc=jbaron@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=masami.hiramatsu.pt@hitachi.com \
--cc=mathieu.desnoyers@polymtl.ca \
--cc=michael@ellerman.id.au \
--cc=mingo@elte.hu \
--cc=peterz@infradead.org \
--cc=roland@redhat.com \
--cc=rth@redhat.com \
--cc=sam@ravnborg.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
all inboxes | Powered by JetHome®