linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Daniel Phillips <phillips@bonn-fries.net>
To: Andrew Morton <akpm@zip.com.au>, lkml <linux-kernel@vger.kernel.org>
Subject: Re: [CFT] delayed allocation and multipage I/O patches for 2.5.6.
Date: Tue, 12 Mar 2002 12:39:28 +0100	[thread overview]
Message-ID: <E16kkcq-0001rV-00@starship> (raw)
In-Reply-To: <3C8D9999.83F991DB@zip.com.au>
In-Reply-To: <3C8D9999.83F991DB@zip.com.au>

On March 12, 2002 07:00 am, Andrew Morton wrote:
> dallocbase-15-pageprivate
> 
>   page->buffers is a bit of a layering violation.  Not all address_spaces
>   have pages which are backed by buffers.
> 
>   The exclusive use of page->buffers for buffers means that a piece of prime
>   real estate in struct page is unavailable to other forms of address_space.
> 
>   This patch turns page->buffers into `unsigned long page->private' and sets
>   in place all the infrastructure which is needed to allow other address_spaces
>   to use this storage.
> 
>   With this change in place, the multipage-bio no-buffer_head code can use
>   page->private to cache the results of an earlier get_block(), so repeated
>   calls into the filesystem are not needed in the case of file overwriting.

That's pragmatic, a good short term solution.  Getting rid of page->buffers 
entirely will be nicer, and in that case you want to cache the physical block
only for those pages that have one, e.g., not for swap-backed pages, which
keep that information in the page table.

I've been playing with the idea of caching the physical block in the radix
tree, which imposes the cost only on cache pages.  This forces you to do a
tree probe at IO time, but that cost is probably insignificant against the
cost of the IO.  This arrangement could make it quite convenient for the
filesystem to exploit the structure by doing opportunistic map-ahead, i.e.,
when ->get_block consults the metadata to fill in one physical address, why
not fill in several more, if it's convenient?

-- 
Daniel

  parent reply	other threads:[~2002-03-12 11:44 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-03-12  6:00 [CFT] delayed allocation and multipage I/O patches for 2.5.6 Andrew Morton
2002-03-12 11:18 ` Daniel Phillips
2002-03-12 20:29   ` Andrew Morton
2002-03-12 20:40     ` Daniel Phillips
2002-03-12 11:39 ` Daniel Phillips [this message]
2002-03-12 21:00   ` Andrew Morton
2002-03-13 11:58     ` Daniel Phillips
2002-03-13 19:50       ` Andrew Morton
2002-03-13 21:51         ` Mike Fedyk
2002-03-14 11:59         ` Daniel Phillips
2002-03-13  0:42   ` David Woodhouse
2002-03-18 19:16 ` Hanna Linder
2002-03-18 20:14   ` Andrew Morton
2002-03-18 20:22     ` Hanna Linder
2002-03-18 20:49       ` Andrew Morton
2002-03-19  0:41 rwhron

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=E16kkcq-0001rV-00@starship \
    --to=phillips@bonn-fries.net \
    --cc=akpm@zip.com.au \
    --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;
as well as URLs for NNTP newsgroup(s).