From: "Jörn Engel" <joern@logfs.org>
To: Andi Kleen <andi@firstfloor.org>
Cc: Johannes Berg <johannes@sipsolutions.net>,
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
Andrew Morton <akpm@linux-foundation.org>,
Linux Kernel list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] add b+tree library
Date: Sat, 10 Jan 2009 21:23:16 +0100 [thread overview]
Message-ID: <20090110202315.GE20611@logfs.org> (raw)
In-Reply-To: <87fxjrgd9s.fsf@basil.nowhere.org>
On Sat, 10 January 2009 20:41:03 +0100, Andi Kleen wrote:
> Johannes Berg <johannes@sipsolutions.net> writes:
>
> > Also, to elaborate on that answer, I'm going to use this as a sort of
> > hash table for wireless, where it ensures better scalability than a pure
> > hashtable from quiet environments (say wireless off on an airplane) to
> > your wireless test lab (100+ access points)
>
> Is there any particular reason you can't use the standard rbtrees
> for that?
Can't think of any. You can use linked lists as well. Whether you want
to is a different matter.
Key difference is the number of cachelines you need to find a particular
entry. rbtrees have a fanout of sqrt(3), so for a million elements (to
pick a random example) you need about 25 cachelines with rbtrees and
about 5-16 with btrees. Closer to 5 if keys and pointers are small and
cachelines are large, closer to 16 if keys and pointers are large and
cachelines are small.
Jörn
--
The key to performance is elegance, not battalions of special cases.
-- Jon Bentley and Doug McIlroy
next prev parent reply other threads:[~2009-01-10 20:23 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-10 10:47 [PATCH] add b+tree library Johannes Berg
2009-01-10 11:02 ` KOSAKI Motohiro
2009-01-10 11:37 ` Johannes Berg
2009-01-10 11:56 ` Jörn Engel
2009-01-10 12:29 ` KOSAKI Motohiro
2009-01-10 18:39 ` Jörn Engel
2009-01-10 18:44 ` Johannes Berg
2009-01-10 19:41 ` Andi Kleen
2009-01-10 20:22 ` Johannes Berg
2009-01-10 20:23 ` Jörn Engel [this message]
2009-01-10 21:27 ` Theodore Tso
2009-01-10 22:01 ` Jörn Engel
2009-01-10 22:23 ` Andrew Morton
2009-01-10 23:57 ` Peter Zijlstra
2009-01-11 8:30 ` Jörn Engel
2009-01-12 16:20 ` Paul E. McKenney
2009-02-05 0:17 ` Johannes Berg
2009-02-05 8:46 ` Andi Kleen
2009-02-07 12:26 ` Jörn Engel
2009-01-11 3:13 ` Theodore Tso
2009-01-10 22:26 ` Andi Kleen
2009-01-11 8:20 ` Jörn Engel
2009-01-11 18:23 ` Andi Kleen
2009-01-17 17:53 ` Pavel Machek
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=20090110202315.GE20611@logfs.org \
--to=joern@logfs.org \
--cc=akpm@linux-foundation.org \
--cc=andi@firstfloor.org \
--cc=johannes@sipsolutions.net \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.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.