From: Andrew Morton <akpm@linux-foundation.org>
To: "Jörn Engel" <joern@logfs.org>
Cc: Theodore Tso <tytso@mit.edu>, Andi Kleen <andi@firstfloor.org>,
Johannes Berg <johannes@sipsolutions.net>,
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
Linux Kernel list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] add b+tree library
Date: Sat, 10 Jan 2009 14:23:30 -0800 [thread overview]
Message-ID: <20090110142330.295a8847.akpm@linux-foundation.org> (raw)
In-Reply-To: <20090110220135.GF20611@logfs.org>
On Sat, 10 Jan 2009 23:01:35 +0100 J__rn Engel <joern@logfs.org> wrote:
> One key difference is that rbtrees maintain the tree within objects and
> btrees maintain the tree externally. So btrees have to allocate memory
> on insertion, where rbtrees have the necessary memory as part of the
> object.
This is a major disadvantage of the btrees.
See all the hoops we ended up jumping through with things like
radix_tree_preload() and idr_pre_get().
The IDR code there wasn't very well designed and still has holes. The
radix-tree code afaik is solid, but look at all the stuff it does!
> With mempools the memory allocation should be reasonably safe,
> so maybe this is a bit of a red herring now.
No, mempools won't help, particularly if items are being added from
atomic contexts.
This is a major major shortcoming which greatly limits the usefulness
of btrees and which greatly reduces the chances of anyone migrating any
rbtree users over to btrees.
next prev parent reply other threads:[~2009-01-10 22:24 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
2009-01-10 21:27 ` Theodore Tso
2009-01-10 22:01 ` Jörn Engel
2009-01-10 22:23 ` Andrew Morton [this message]
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=20090110142330.295a8847.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=andi@firstfloor.org \
--cc=joern@logfs.org \
--cc=johannes@sipsolutions.net \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=tytso@mit.edu \
/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