[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1290611478.2072.482.camel@laptop>
Date: Wed, 24 Nov 2010 16:11:18 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Jason Baron <jbaron@...hat.com>
Cc: rostedt@...dmis.org, mingo@...e.hu, mathieu.desnoyers@...ymtl.ca,
hpa@...or.com, 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 1/3] jump label: add enabled/disabled state to jump
label key entries
On Wed, 2010-11-24 at 09:54 -0500, Jason Baron wrote:
> On Wed, Nov 24, 2010 at 09:20:09AM +0100, Peter Zijlstra wrote:
> > On Tue, 2010-11-23 at 16:27 -0500, Jason Baron wrote:
> > > struct hlist_head modules;
> > > unsigned long key;
> > > + u32 nr_entries : 31,
> > > + enabled : 1;
> > > };
> >
> > I still don't see why you do this, why not simply mandate that the key
> > is of type atomic_t* and use *key as enabled state?
> >
>
> Because I want to use *key as a pointer directly to 'struct jump_label_entry'.
> In this way jump_label_enable(), jump_label_disable(), become O(1) operations.
> That way we don't need any hashing.
But but but, you're doing a friggin stop_machine to poke text, that's
way more expensive than anything else.
You can do away with the hash by using the bsearch stuff Andi has been
proposing.
Also, I'd actually like to have more than 1 bit of storage, I'm using it
as a general refcount.
--
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