public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Martin Mares <mj@ucw.cz>
To: Robert Love <rml@tech9.net>
Cc: William Lee Irwin III <wli@holomorphy.com>, linux-kernel@vger.kernel.org
Subject: Re: [RFC] tree-based bootmem
Date: Mon, 26 Nov 2001 22:02:03 +0100	[thread overview]
Message-ID: <20011126220203.I215@ucw.cz> (raw)
In-Reply-To: <20011117011415.B1180@holomorphy.com> <20011118001657.A467@ucw.cz> <20011117160134.A11913@holomorphy.com> <1006157288.869.0.camel@phantasy>
In-Reply-To: <1006157288.869.0.camel@phantasy>

Hello!

> The beauty is in the implementation.  With a linked list implementation,
> you have an exhaustive search and and at-worst O(n) insertion and
> searching complexity.  We also don't end up with any clean way to say
> "memory a belongs to x".  This is where the segment tree comes in, a
> segment tree stores intervals: it is a binary tree where each node
> represents an interval from a to b.  We only need to store nodes that
> have allocated intervals of memory, and insertion is O(log n). 
> Searching is even easier as you just walk the intervals until we get to
> what we want.  Searching would be O(log(n+s)) where s is the number of
> segments we had to walk.  OK, you know this, but my point is its is
> quite applicable.  Besides a performance boost, we end up with a nice
> way to interface with other code to work with bootmem and I think that
> is the main benefit here.

Look at it from the other side: Compare a simple 50-line allocator based
on linked lists which is obviously correct and a complex allocator with
several hundreds lines of code which, although very fast and elegant,
is very far from being understandable in a couple of minutes. And believe
me, bugs in memory allocators are some of the worst to find.

On the other hand, well implemented segment trees might be much more useful for
other stuff, like the vm_area_struct lists.

				Have a nice fortnight
-- 
Martin `MJ' Mares   <mj@ucw.cz>   http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
"I don't give a damn for a man that can only spell a word one way." -- M. Twain

  reply	other threads:[~2001-11-26 21:58 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-11-17  9:14 [RFC] tree-based bootmem William Lee Irwin III
     [not found] ` <20011118001657.A467@ucw.cz>
2001-11-18  0:01   ` William Lee Irwin III
2001-11-19  8:08     ` Robert Love
2001-11-26 21:02       ` Martin Mares [this message]
2001-11-21 16:20 ` William Lee Irwin III
2001-11-23  9:30 ` William Lee Irwin III
2001-11-28  9:04 ` Chris Wright
2001-11-28 12:40   ` William Lee Irwin III
2001-11-29  0:33     ` Chris Wright
2001-11-29  1:23   ` William Lee Irwin III
2001-11-30  2:29     ` Robert Love
2001-12-02  6:59       ` William Lee Irwin III
2001-12-02  7:08         ` Anton Blanchard
     [not found] <20011118005819.3762.qmail@science.horizon.com>
2001-11-18  1:24 ` William Lee Irwin III

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=20011126220203.I215@ucw.cz \
    --to=mj@ucw.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rml@tech9.net \
    --cc=wli@holomorphy.com \
    /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