[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1297452328.5226.89.camel@laptop>
Date: Fri, 11 Feb 2011 20:25:28 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Jason Baron <jbaron@...hat.com>
Cc: mathieu.desnoyers@...ymtl.ca, hpa@...or.com, rostedt@...dmis.org,
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 0/2] jump label: 2.6.38 updates
On Wed, 2011-01-05 at 10:43 -0500, Jason Baron 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 static_branch(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 (static_branch(&jump_key))
> do unlikely code
>
> enable/disale via:
>
> jump_label_enable(&jump_key);
> jump_label_disable(&jump_key);
>
> that's it!
>
> For perf, which also uses jump labels, I've left the reference counting
> out of the jump label layer, thus removing the 'jump_label_inc()' and
> 'jump_label_dec()' interface. Hopefully, this is a more palatable solution.
Right, lets go with this. Maybe we'll manage to come up with something
saner than _else_atomic_read(), but for now its an improvement over what
we have.
--
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