From: "Jörn Engel" <joern@logfs.org>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: 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 12:56:27 +0100 [thread overview]
Message-ID: <20090110115626.GC20611@logfs.org> (raw)
In-Reply-To: <1231587428.3803.0.camel@johannes>
On Sat, 10 January 2009 12:37:08 +0100, Johannes Berg wrote:
> On Sat, 2009-01-10 at 20:02 +0900, KOSAKI Motohiro wrote:
>
> > > This adds a b+tree library. The API and memory layout is documented in
> > > the header file lib/btree.h. There are tree versions for 32, 64 and
> > > 128 bit keys as well as unsigned long (32/64 depending on platform).
> >
> > Can this library remove the btree code in some btree based filesystem?
>
> Joern is going to use it for logfs, that's the point. Not sure about
> other filesystems.
Err...
While true, this is decidedly _not_ a disk-based btree. Logfs uses it
for in-memory data structures. So the short answer is no.
There are several differences between this implementation and one used
for disk data.
- The value is a pointer, 32/64bit depending on architecture. Won't be
suited for a 64bit filesystem on a 32bit host, f.e.
- Lookups are a simple loop and don't use binary search. With a 4KiB
btree node and 64B cacheline, binary search will only load 7 out of 64
cachelines - making a big difference. This implementation uses 128B
(or cacheline size, whichever is bigger) nodes, so binary search buy
almost nothing, but cause branch mispredictions, bigger code, etc.
There may be more. So if you plan to replace disk-based btree code with
this, it will certainly be some amount of work. Not sure if it is a
good idea or if one should rather have a seperate library.
Jörn
--
The cost of changing business rules is much more expensive for software
than for a secretaty.
-- unknown
next prev parent reply other threads:[~2009-01-10 11:56 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 [this message]
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
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=20090110115626.GC20611@logfs.org \
--to=joern@logfs.org \
--cc=akpm@linux-foundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox