public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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

  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