From: Daniel Phillips <phillips@arcor.de>
To: William Lee Irwin III <wli@holomorphy.com>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [RFC] My research agenda for 2.7
Date: Wed, 25 Jun 2003 03:25:47 +0200 [thread overview]
Message-ID: <200306250325.47529.phillips@arcor.de> (raw)
In-Reply-To: <20030625011031.GP26348@holomorphy.com>
On Wednesday 25 June 2003 03:10, William Lee Irwin III wrote:
> On Wednesday 25 June 2003 02:47, William Lee Irwin III wrote:
> >> Per struct address_space? This is an unnecessary limitation.
>
> On Wed, Jun 25, 2003 at 03:07:18AM +0200, Daniel Phillips wrote:
> > It's a sensible limitation, it keeps the radix tree lookup simple.
>
> It severely limits its usefulness. Dropping in a more flexible data
> structure should be fine.
Eventually it could well make sense to do that, e.g., the radix tree
eventually ought to evolve into a btree of extents (probably). But making
things so complex in the first version, thus losing much of the incremental
development advantage, would not be smart. With a single size of page per
address_space, changes to the radix tree code are limited to a couple of
lines, for example.
But perhaps you'd like to supply some examples where more than one size of
page in the same address space really matters?
> On Wednesday 25 June 2003 02:47, William Lee Irwin III wrote:
> >> This gives me the same data structure proliferation chills as bh's.
>
> On Wed, Jun 25, 2003 at 03:07:18AM +0200, Daniel Phillips wrote:
> > It's not nearly as bad. There is no distinction between subpage and base
> > struct page for almost all page operations, e.g., locking, IO, data
> > access.
>
> But those are code sanitation issues. You need to make sure this
> doesn't explode on PAE.
Indeed, that is important. Good night, see you tomorrow.
Daniel
next prev parent reply other threads:[~2003-06-25 1:12 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-06-24 23:11 [RFC] My research agenda for 2.7 Daniel Phillips
2003-06-25 0:47 ` William Lee Irwin III
2003-06-25 1:07 ` Daniel Phillips
2003-06-25 1:10 ` William Lee Irwin III
2003-06-25 1:25 ` Daniel Phillips [this message]
2003-06-25 1:30 ` William Lee Irwin III
2003-06-25 9:29 ` Mel Gorman
2003-06-26 19:00 ` Daniel Phillips
2003-06-26 19:00 ` Daniel Phillips
2003-06-26 20:01 ` Mel Gorman
2003-06-26 20:01 ` Mel Gorman
2003-06-26 20:10 ` Andrew Morton
2003-06-26 20:10 ` Andrew Morton
2003-06-27 0:30 ` Daniel Phillips
2003-06-27 0:30 ` Daniel Phillips
2003-06-27 13:00 ` Mel Gorman
2003-06-27 13:00 ` Mel Gorman
2003-06-27 14:38 ` Martin J. Bligh
2003-06-27 14:38 ` Martin J. Bligh
2003-06-27 14:41 ` Daniel Phillips
2003-06-27 14:41 ` Daniel Phillips
2003-06-27 14:43 ` Martin J. Bligh
2003-06-27 14:43 ` Martin J. Bligh
2003-06-27 14:54 ` Daniel Phillips
2003-06-27 14:54 ` Daniel Phillips
2003-06-27 15:04 ` Martin J. Bligh
2003-06-27 15:04 ` Martin J. Bligh
2003-06-27 15:17 ` Daniel Phillips
2003-06-27 15:17 ` Daniel Phillips
2003-06-27 15:22 ` Mel Gorman
2003-06-27 15:22 ` Mel Gorman
2003-06-27 15:50 ` Daniel Phillips
2003-06-27 15:50 ` Daniel Phillips
2003-06-27 16:00 ` Daniel Phillips
2003-06-27 16:00 ` Daniel Phillips
2003-06-29 19:25 ` Mel Gorman
2003-06-29 19:25 ` Mel Gorman
2003-06-28 21:06 ` Daniel Phillips
2003-06-28 21:06 ` Daniel Phillips
2003-06-29 21:26 ` Mel Gorman
2003-06-29 21:26 ` Mel Gorman
2003-06-28 21:54 ` Daniel Phillips
2003-06-28 21:54 ` Daniel Phillips
2003-06-29 22:07 ` William Lee Irwin III
2003-06-29 22:07 ` William Lee Irwin III
2003-06-28 23:18 ` Daniel Phillips
2003-06-28 23:18 ` Daniel Phillips
2003-07-02 21:10 ` Mike Fedyk
2003-07-02 21:10 ` Mike Fedyk
2003-07-03 2:04 ` Larry McVoy
2003-07-03 2:04 ` Larry McVoy
2003-07-03 2:20 ` William Lee Irwin III
2003-07-03 2:20 ` 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=200306250325.47529.phillips@arcor.de \
--to=phillips@arcor.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.