All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Nick Piggin <nickpiggin@yahoo.com.au>
Cc: Hisashi Hifumi <hifumi.hisashi@oss.ntt.co.jp>,
	Christoph Hellwig <hch@infradead.org>,
	jack@ucw.cz, linux-ext4@vger.kernel.org,
	linux-fsdevel@vger.kernel.org, xfs@oss.sgi.com
Subject: Re: partially uptodate page reads
Date: Mon, 28 Jul 2008 00:09:08 -0700	[thread overview]
Message-ID: <20080728000908.869c3e85.akpm@linux-foundation.org> (raw)
In-Reply-To: <200807281656.37908.nickpiggin@yahoo.com.au>

On Mon, 28 Jul 2008 16:56:37 +1000 Nick Piggin <nickpiggin@yahoo.com.au> wrote:

> On Monday 28 July 2008 16:51, Andrew Morton wrote:
> > 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.
> 
> Yeah, thanks for the numbers.
> 
> 
> > OK, thanks.  Those are pretty nice numbers for what is probably a
> > fairly common workload.
> 
> What kind of workloads does this kind of thing?

Various databases?  (confused).

More likely pattern is 8k IOs with 16k pagesize or thereabouts.

  reply	other threads:[~2008-07-28  7:09 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 [this message]
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=20080728000908.869c3e85.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.