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:07:18 +0200 [thread overview]
Message-ID: <200306250307.18291.phillips@arcor.de> (raw)
In-Reply-To: <20030625004758.GO26348@holomorphy.com>
On Wednesday 25 June 2003 02:47, William Lee Irwin III wrote:
> On Wed, Jun 25, 2003 at 01:11:01AM +0200, Daniel Phillips wrote:
> > - Page size is represented on a per-address space basis with a shift
> > count. In practice, the smallest is 9 (512 byte sector), could imagine 7
> > (each ext2 inode is separate page) or 8 (actual hardsect size on some
> > drives). 12 will be the most common size. 13 gives 8K blocksize for,
> > e.g., alpha. 21 and 22 give 2M and 4M page size, matching hardware
> > capabilities of x86, and other sizes are possible on machines like MIPS,
> > where page size is software controllable
> > - Implemented only for file-backed memory (page cache)
>
> Per struct address_space? This is an unnecessary limitation.
It's a sensible limitation, it keeps the radix tree lookup simple.
> On Wed, Jun 25, 2003 at 01:11:01AM +0200, Daniel Phillips wrote:
> > - Special case these ops in page cache access layer instead of having
> > the messy code in the block IO library
> > - Subpage struct pages are dynamically allocated. But buffer_heads are
> > gone so this is a lateral change.
>
> This gives me the same data structure proliferation chills as bh's.
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.
Regards,
Daniel
next prev parent reply other threads:[~2003-06-25 1:07 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-06-24 23:11 Daniel Phillips
2003-06-25 0:47 ` William Lee Irwin III
2003-06-25 1:07 ` Daniel Phillips [this message]
2003-06-25 1:10 ` William Lee Irwin III
2003-06-25 1:25 ` Daniel Phillips
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 20:01 ` Mel Gorman
2003-06-26 20:10 ` Andrew Morton
2003-06-27 0:30 ` Daniel Phillips
2003-06-27 13:00 ` Mel Gorman
2003-06-27 14:38 ` Martin J. Bligh
2003-06-27 14:41 ` Daniel Phillips
2003-06-27 14:43 ` Martin J. Bligh
2003-06-27 14:54 ` Daniel Phillips
2003-06-27 15:04 ` Martin J. Bligh
2003-06-27 15:17 ` Daniel Phillips
2003-06-27 15:22 ` Mel Gorman
2003-06-27 15:50 ` Daniel Phillips
2003-06-27 16:00 ` Daniel Phillips
2003-06-29 19:25 ` Mel Gorman
2003-06-28 21:06 ` Daniel Phillips
2003-06-29 21:26 ` Mel Gorman
2003-06-28 21:54 ` Daniel Phillips
2003-06-29 22:07 ` William Lee Irwin III
2003-06-28 23:18 ` Daniel Phillips
2003-07-02 21:10 ` Mike Fedyk
2003-07-03 2:04 ` Larry McVoy
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=200306250307.18291.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox