From: Suparna Bhattacharya <suparna@in.ibm.com>
To: Chris Mason <mason@suse.com>
Cc: linux-aio@kvack.org, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: aio-stress throughput regressions from 2.6.11 to 2.6.12
Date: Wed, 6 Jul 2005 16:07:29 +0530 [thread overview]
Message-ID: <20050706103729.GA4600@in.ibm.com> (raw)
In-Reply-To: <200507051000.25591.mason@suse.com>
On Tue, Jul 05, 2005 at 10:00:24AM -0400, Chris Mason wrote:
> On Friday 01 July 2005 03:56, Suparna Bhattacharya wrote:
> > Has anyone else noticed major throughput regressions for random
> > reads/writes with aio-stress in 2.6.12 ?
> > Or have there been any other FS/IO regressions lately ?
> >
> > On one test system I see a degradation from around 17+ MB/s to 11MB/s
> > for random O_DIRECT AIO (aio-stress -o3 testext3/rwfile5) from 2.6.11
> > to 2.6.12. It doesn't seem filesystem specific. Not good :(
> >
> > BTW, Chris/Ben, it doesn't look like the changes to aio.c have had an
> > impact (I copied those back to my 2.6.11 tree and tried the runs with no
> > effect) So it is something else ...
> >
> > Ideas/thoughts/observations ?
>
> Lets try to narrow it down a bit:
>
> aio-stress -o 3 -d 1 will set the depth to 1, (io_submit then wait one request
This doesn't regress - the problem really happens when we don't wait one
at a time.
> at a time). This doesn't take the aio subsystem out of the picture, but it
> does make the block layer interaction more or less the same as non-aio
> benchmarks. If this is slow, I would suspect something in the block layer,
> and iozone -I -i 2 -w -f testext3/rwfile5 should also show the regression.
>
> If it doesn't regress, I would suspect something in the aio core. My first
> attempts at the context switch reduction patches caused this kind of
> regression. There was too much latency in sending the events up to userland.
>
> Other options:
>
> Try different elevators
Still regresses (I tried noop instead of as)
> Try O_SYNC aio random writes
> Try aio random reads
> Try buffers random reads
Again all these end up waiting one at a time with mainline because it
forces buffered AIO to be synchronous, so we the regression doesn't
show up. But, when I apply my patches to make buffered fsAIO async,
so we aren't waiting one at a time -- there is a similar regression.
In fact it was this regression that made me go back and check if it
was happening with AIO-DIO as well.
Regards
Suparna
>
> -chris
--
Suparna Bhattacharya (suparna@in.ibm.com)
Linux Technology Center
IBM Software Lab, India
WARNING: multiple messages have this Message-ID (diff)
From: Suparna Bhattacharya <suparna@in.ibm.com>
To: Chris Mason <mason@suse.com>
Cc: linux-aio@kvack.org, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: aio-stress throughput regressions from 2.6.11 to 2.6.12
Date: Wed, 6 Jul 2005 16:07:29 +0530 [thread overview]
Message-ID: <20050706103729.GA4600@in.ibm.com> (raw)
In-Reply-To: <200507051000.25591.mason@suse.com>
On Tue, Jul 05, 2005 at 10:00:24AM -0400, Chris Mason wrote:
> On Friday 01 July 2005 03:56, Suparna Bhattacharya wrote:
> > Has anyone else noticed major throughput regressions for random
> > reads/writes with aio-stress in 2.6.12 ?
> > Or have there been any other FS/IO regressions lately ?
> >
> > On one test system I see a degradation from around 17+ MB/s to 11MB/s
> > for random O_DIRECT AIO (aio-stress -o3 testext3/rwfile5) from 2.6.11
> > to 2.6.12. It doesn't seem filesystem specific. Not good :(
> >
> > BTW, Chris/Ben, it doesn't look like the changes to aio.c have had an
> > impact (I copied those back to my 2.6.11 tree and tried the runs with no
> > effect) So it is something else ...
> >
> > Ideas/thoughts/observations ?
>
> Lets try to narrow it down a bit:
>
> aio-stress -o 3 -d 1 will set the depth to 1, (io_submit then wait one request
This doesn't regress - the problem really happens when we don't wait one
at a time.
> at a time). This doesn't take the aio subsystem out of the picture, but it
> does make the block layer interaction more or less the same as non-aio
> benchmarks. If this is slow, I would suspect something in the block layer,
> and iozone -I -i 2 -w -f testext3/rwfile5 should also show the regression.
>
> If it doesn't regress, I would suspect something in the aio core. My first
> attempts at the context switch reduction patches caused this kind of
> regression. There was too much latency in sending the events up to userland.
>
> Other options:
>
> Try different elevators
Still regresses (I tried noop instead of as)
> Try O_SYNC aio random writes
> Try aio random reads
> Try buffers random reads
Again all these end up waiting one at a time with mainline because it
forces buffered AIO to be synchronous, so we the regression doesn't
show up. But, when I apply my patches to make buffered fsAIO async,
so we aren't waiting one at a time -- there is a similar regression.
In fact it was this regression that made me go back and check if it
was happening with AIO-DIO as well.
Regards
Suparna
>
> -chris
--
Suparna Bhattacharya (suparna@in.ibm.com)
Linux Technology Center
IBM Software Lab, India
--
To unsubscribe, send a message with 'unsubscribe linux-aio' in
the body to majordomo@kvack.org. For more info on Linux AIO,
see: http://www.kvack.org/aio/
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>
next prev parent reply other threads:[~2005-07-06 15:04 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-07-01 7:56 aio-stress throughput regressions from 2.6.11 to 2.6.12 Suparna Bhattacharya
2005-07-01 7:56 ` Suparna Bhattacharya
2005-07-01 14:25 ` Benjamin LaHaise
2005-07-06 4:30 ` Suparna Bhattacharya
2005-07-08 17:58 ` Benjamin LaHaise
2005-07-08 17:58 ` Benjamin LaHaise
2005-07-05 14:00 ` Chris Mason
2005-07-05 14:00 ` Chris Mason
2005-07-05 16:12 ` Benjamin LaHaise
2005-07-05 16:12 ` Benjamin LaHaise
2005-07-06 10:37 ` Suparna Bhattacharya [this message]
2005-07-06 10:37 ` Suparna Bhattacharya
2005-07-06 12:10 ` aio-stress regressions in 2.6.12 narrowed down to AIC7xxx Suparna Bhattacharya
2005-07-11 7:43 ` aio-stress throughput regressions from 2.6.11 to 2.6.12 Sébastien Dugué
2005-07-11 7:43 ` Sébastien Dugué
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=20050706103729.GA4600@in.ibm.com \
--to=suparna@in.ibm.com \
--cc=linux-aio@kvack.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mason@suse.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.