From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Christoph Hellwig <hch@infradead.org>
Cc: hifumi.hisashi@oss.ntt.co.jp, jack@ucw.cz,
linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org,
akpm@linux-foundation.org, xfs@oss.sgi.com
Subject: Re: partially uptodate page reads
Date: Fri, 25 Jul 2008 19:22:39 +1000 [thread overview]
Message-ID: <200807251922.40299.nickpiggin@yahoo.com.au> (raw)
In-Reply-To: <20080724175913.GA32117@infradead.org>
On Friday 25 July 2008 03:59, Christoph Hellwig wrote:
> On Fri, Jul 25, 2008 at 01:17:11AM +1000, Nick Piggin wrote:
> > Hi, I have some questions about your patch in -mm
> >
> > vfs-pagecache-usage-optimization-onpagesize=blocksize-environment.patch
> >
> > I have no particular problem with something like this, but leaving the
> > implementation details aside for the moment, can we discuss the
> > justification for this?
> >
> > Are there significant numbers of people using block size < page size in
> > situations where performance is important and significantly improved by
> > this patch? Can you give any performance numbers to illustrate perhaps?
>
> With XFS lots of people use 4k blocksize filesystems on ia64 systems
> with 16k pages, so an optimization like this would be useful.
>
> But as mentioned in one of your previous comments I'd rather prefer
> a readpage interface chaneg to deal with this.
Yeah... actually if it is a nice win I don't mind too much to go
with this API to start with, and consolidate with readpage later.
Readpage I am thinking about making a few other changes for it as
well, so I am happy to look at folding in this partially-uptodate
API with it as well.
If we just get some numbers (maybe SGI can help out?), I'm happy
enough with this approach.
prev parent reply other threads:[~2008-07-25 9:22 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-24 15:17 partially uptodate page reads Nick Piggin
2008-07-24 17:59 ` Christoph Hellwig
2008-07-24 19:08 ` Andrew Morton
2008-07-28 4:34 ` Hisashi Hifumi
2008-07-28 6:51 ` Andrew Morton
2008-07-28 6:56 ` Nick Piggin
2008-07-28 7:09 ` Andrew Morton
2008-07-28 7:22 ` Nick Piggin
2008-07-25 9:22 ` Nick Piggin [this message]
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=200807251922.40299.nickpiggin@yahoo.com.au \
--to=nickpiggin@yahoo.com.au \
--cc=akpm@linux-foundation.org \
--cc=hch@infradead.org \
--cc=hifumi.hisashi@oss.ntt.co.jp \
--cc=jack@ucw.cz \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=xfs@oss.sgi.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.