From: William Lee Irwin III <wli@holomorphy.com>
To: Martin Mares <mj@ucw.cz>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [RFC] tree-based bootmem
Date: Sat, 17 Nov 2001 16:01:34 -0800 [thread overview]
Message-ID: <20011117160134.A11913@holomorphy.com> (raw)
In-Reply-To: <20011117011415.B1180@holomorphy.com> <20011118001657.A467@ucw.cz>
In-Reply-To: <20011118001657.A467@ucw.cz>; from mj@ucw.cz on Sun, Nov 18, 2001 at 12:16:57AM +0100
On Sun, Nov 18, 2001 at 12:16:57AM +0100, Martin Mares wrote:
> I don't understand why does it use segment trees instead of a simple
> linked list. Bootmem allocations are obviously not going to be time
> critical and shaving off a couple of ms during the boot process is
> not worth the extra complexity involved.
>
> (Nevertheless, treaps are a very nice structure...)
>
> Have a nice fortnight
Thanks for your comments.
Your opinions are valid and worthwhile, and I hope you don't mind if I
Cc: the Linux kernel mailing list in my reply.
The trees are largely there out of a personal distaste for exhaustive
search when not strictly necessary. My approach to this was to research
what data structures were appropriate for the search problem I found,
and to use that in preference to exhaustive search.
Some profiling by Jack Steiner prior to the initial post of this patch
to lkml revealed that it is a very rare system that has any issues with
the performance of the bitmap-based bootmem, and it's even less likely
there will be a noticeable difference in absolute terms between a search
tree structure and a linked list of ranges. While there were some
performance concerns motivating this, the primary concern was
interfacing with the callers and requiring less work to set up; that is,
making it easier to say "This memory belongs to this node." I had hoped
that in addition to suggestions regarding the mechanics, some suggestions
about how to make life easier for those who have to call bootmem
functions might arise from discussions about this.
Part of the motivation for the RFC is to solicit commentary like this
regarding the design, and in my responses, to adjust, alter, or even
entirely rewrite this patch in order to produce something useful and
desirable to the largest number of people. If linked lists are wanted,
then they can be used instead.
Is there a more general consensus regarding this aspect of the design?
Thanks,
Bill
next prev parent reply other threads:[~2001-11-18 0:02 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 [this message]
2001-11-19 8:08 ` Robert Love
2001-11-26 21:02 ` Martin Mares
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=20011117160134.A11913@holomorphy.com \
--to=wli@holomorphy.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mj@ucw.cz \
/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