From: Andrew Morton <akpm@linux-foundation.org>
To: Hisashi Hifumi <hifumi.hisashi@oss.ntt.co.jp>
Cc: Christoph Hellwig <hch@infradead.org>,
Nick Piggin <nickpiggin@yahoo.com.au>,
jack@ucw.cz, linux-ext4@vger.kernel.org,
linux-fsdevel@vger.kernel.org, xfs@oss.sgi.com
Subject: Re: partially uptodate page reads
Date: Sun, 27 Jul 2008 23:51:24 -0700 [thread overview]
Message-ID: <20080727235124.5b04fd8b.akpm@linux-foundation.org> (raw)
In-Reply-To: <6.0.0.20.2.20080728115511.045088a8@172.19.0.2>
On Mon, 28 Jul 2008 13:34:12 +0900 Hisashi Hifumi <hifumi.hisashi@oss.ntt.co.jp> wrote:
> Hi
>
> >> >
> >> > 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.
> >
> >As Nick says, we really should have some measurement results which
> >confirm this theory. Maybe we did do some but they didn't find theor
> >way into the changelog.
> >
> >I've put the patch on hold until this confirmation data is available.
> >
>
> I've got some performance number.
> I wrote a benchmark program and got result number with this program.
> This benchmark do:
> 1, mount and open a test file.
> 2, create a 512MB file.
> 3, close a file and umount.
> 4, mount and again open a test file.
> 5, pwrite randomly 300000 times on a test file. offset is aligned by IO size(1024bytes).
> 6, measure time of preading randomly 100000 times on a test file.
>
> The result was:
> 2.6.26
> 330 sec
>
> 2.6.26-patched
> 226 sec
>
> Arch:i386
> Filesystem:ext3
> Blocksize:1024 bytes
> Memory: 1GB
>
> On ext3/4, a file is written through buffer/block. So random read/write mixed workloads
> or random read after random write workloads are optimized with this patch under
> pagesize != blocksize environment. This test result showed this.
OK, thanks. Those are pretty nice numbers for what is probably a
fairly common workload.
next prev parent reply other threads:[~2008-07-28 6:51 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 [this message]
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
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=20080727235124.5b04fd8b.akpm@linux-foundation.org \
--to=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=nickpiggin@yahoo.com.au \
--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.