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: linux-kernel@vger.kernel.org
Subject: Re: [RFC] B+Tree library V2
Date: Thu, 8 Jan 2009 20:40:32 +0100	[thread overview]
Message-ID: <20090108194031.GB24884@logfs.org> (raw)
In-Reply-To: <1231432450.8038.4.camel@johannes>

On Thu, 8 January 2009 17:34:10 +0100, Johannes Berg wrote:
> 
> > Well, I used to have heaps of btrees around and wanted to share the
> > mempool between all of them.  Not sure if I still do, I believe not.
> > Will check.
> > 
> > If mempools aren't shared, I agree that encapsulating those bits is much
> > nicer.
> 
> Just made the API a bit quirky, maybe just support both ways of using
> things? Would only need a flag somewhere in the btree structure, I'd
> think; ultimately it doesn't matter much to me though.

I don't think we need a flag.  Just a regular pair of init/cleanup
functions and some __init_i_want_to_share_mempools_and_crawl_on_my_knees
without a cleanup for those who need it.

> > If you want to open-code it, you can use btree_lookup_less().  I added
> > that function sometime last month.  Basically something like this:
> > 	key = btree_last(head, geo);
> > 	while (key) {
> > 		/* do something with key */
> > 		key = btree_lookup_less(head, geo, key);
> > 	}
> > 
> > Maybe it should be renamed to btree_get_prev_key().  I never noticed how
> > confusing it was because my head was busy with other problems.  The code
> > is currently burried within my logfs tree:
> > http://logfs.org/git?p=logfs;a=summary
> 
> I don't think I've understood this yet. That code above there is a
> backwards walk over the key space, and it's safe to call
> btree_remove(key) at /* do something with key */?

Yes, it's a backwards walk.  The btree is sorted backwards as a
micro-optimization.  Loops will terminate a bit earlier without a
complicated test this way.

And you can do absolutely anything at  /* do something with key */.  The
btree_get_prev_key() will simply tell you what the next-lowest key in
the btree is at that time.  You no longer need locking around the whole
visitor, but can release the lock after each step, if you want.

Downside is that each step will walk the btree from the root again.
Twice, because you also need to lookup/remove each element.  Tanstaafl.

Jörn

-- 
Courage is not the absence of fear, but rather the judgement that
something else is more important than fear.
-- Ambrose Redmoon

  reply	other threads:[~2009-01-08 19:40 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-26 12:46 [RFC] B+Tree library Jörn Engel
2008-10-28  1:25 ` Dave Chinner
2008-10-30 17:43 ` Pavel Machek
2008-10-30 17:58   ` Jörn Engel
2008-10-30 19:14     ` Pavel Machek
2008-10-30 20:20       ` Jörn Engel
2008-10-31  6:38     ` Christian Borntraeger
2008-10-31  7:35       ` Jörn Engel
2008-10-31  9:16         ` Geert Uytterhoeven
2008-10-31  9:20           ` Jörn Engel
2008-10-31 10:35 ` Johannes Berg
2008-10-31 11:26   ` Jörn Engel
2008-10-31 11:32     ` Johannes Berg
2008-10-31 12:54       ` Jörn Engel
2008-10-31 13:07         ` Johannes Berg
2008-10-31 13:15           ` Jörn Engel
2008-11-01 15:59         ` [RFC] B+Tree library V2 Jörn Engel
2008-11-05 19:57           ` Johannes Berg
2008-11-05 20:06             ` Jörn Engel
2008-11-05 20:12               ` Johannes Berg
2008-11-05 20:21                 ` Jörn Engel
2008-11-05 20:25                   ` Johannes Berg
2008-11-07  7:52                     ` Jörn Engel
2009-01-08  0:57           ` Johannes Berg
2009-01-08 16:24             ` Jörn Engel
2009-01-08 16:34               ` Johannes Berg
2009-01-08 19:40                 ` Jörn Engel [this message]
2009-01-08 16:50               ` Johannes Berg
2009-01-08 19:46                 ` Jörn Engel
2009-01-08 17:10               ` Johannes Berg
2009-01-08 20:02                 ` Jörn Engel
2009-01-08 20:18                   ` Johannes Berg
2009-01-08 21:09                     ` Jörn Engel
2008-10-31 13:16 ` [RFC] B+Tree library Johannes Berg
2008-10-31 13:29   ` Jörn Engel
2008-10-31 13:45   ` Bert Wesarg
2008-10-31 15:18   ` Tim Gardner
2008-10-31 15:35     ` Jörn Engel
2008-10-31 20:17 ` Sean Young
2008-10-31 23:36   ` Jörn Engel
2008-11-01 10:17     ` Sean Young

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=20090108194031.GB24884@logfs.org \
    --to=joern@logfs.org \
    --cc=johannes@sipsolutions.net \
    --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