From: Ryan Harper <ryanh@us.ibm.com>
To: Anthony Liguori <aliguori@us.ibm.com>
Cc: Ryan Harper <ryanh@us.ibm.com>,
qemu-devel@nongnu.org, kvm@vger.kernel.org
Subject: Re: [Qemu-devel] [5323] Implement an fd pool to get real AIO with posix-aio
Date: Fri, 26 Sep 2008 13:50:57 -0500 [thread overview]
Message-ID: <20080926185057.GA31395@us.ibm.com> (raw)
In-Reply-To: <48DD2B67.407@us.ibm.com>
* Anthony Liguori <aliguori@us.ibm.com> [2008-09-26 13:37]:
> Ryan Harper wrote:
> >* Anthony Liguori <anthony@codemonkey.ws> [2008-09-26 11:03]:
> >kvm: cache=on posix-aio w/o patch |127.0 | 115.78 | 9.19
> >kvm: cache=on posix-aio w/ patch |126.0 | 67.35 | 9.30
> >
>
> It looks like 127mb/s is pretty close to the optimal cached write time.
> When using caching, writes can complete almost immediately so it's not
> surprising that submission latency is so low (even though it's blocking
> during submission).
>
> I am surprised that w/patch has a latency that's so high. I think that
> suggests that requests are queuing up. I bet increasing the aio_num
> field would reduce this number.
Yeah, there is plenty of room to twiddle with the threads and number of
outstanding ios, but that'll take quite a bit of time to generate the
data and compare.
> >------------ new results
> >----------+------+------------------+------------------
> >kvm:cache=off posix-aio fd_pool[16]| 33.5 | 14.28 | 49.19
> >kvm:cache=off posix-aio fd_pool[64]| 51.1 | 14.86 | 23.66
> >
>
> I assume you tried to bump from 64 to something higher and couldn't make
> up the lost bandwidth?
Very slightly, switching to 128 threads/fds gave another 1MB/s.
> >16k write 1 thread, 74 iodepth | MB/s | avg sub lat (us) | avg comp
> >lat (ms)
> >-----------------------------------+------+------------------+------------------
> >baremetal (O_DIRECT, aka cache=off)|128.1 | 10.90 | 9.45
> >kvm: cache=off posix-aio w/o patch | 5.1 | 3152.00 | 231.06
> >kvm: cache=off linux-aio |130.0 | 83.83 | 8.99
> >kvm: cache=on posix-aio w/o patch |184.0 | 80.46 | 6.35
> >kvm: cache=on posix-aio w/ patch |165.0 | 70.90 | 7.09
> >------------ new results
> >----------+------+------------------+------------------
> >kvm:cache=off posix-aio fd_pool[16]| 78.2 | 58.24 | 15.43
> >kvm:cache=off posix-aio fd_pool[64]|129.0 | 71.62 | 9.11
> >
>
> That's a nice result. We could probably improve the latency by tweaking
> the queue sizes.
Yeah, I was quite pleased to see a simpler solution perform so well.
>
> Very nice work! Thanks for doing the thorough analysis.
Thanks, very happy to see a signficant improvement in IO here.
--
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
(512) 838-9253 T/L: 678-9253
ryanh@us.ibm.com
next prev parent reply other threads:[~2008-09-26 18:51 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-26 15:59 [Qemu-devel] [5323] Implement an fd pool to get real AIO with posix-aio Anthony Liguori
2008-09-26 17:59 ` Ryan Harper
2008-09-26 18:35 ` Anthony Liguori
2008-09-26 18:50 ` Ryan Harper [this message]
2008-10-07 15:43 ` Gerd Hoffmann
2008-10-07 16:01 ` Anthony Liguori
2008-10-07 20:40 ` Gerd Hoffmann
2008-10-07 21:21 ` Anthony Liguori
2008-10-07 22:15 ` Gerd Hoffmann
2008-10-07 22:39 ` Anthony Liguori
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=20080926185057.GA31395@us.ibm.com \
--to=ryanh@us.ibm.com \
--cc=aliguori@us.ibm.com \
--cc=kvm@vger.kernel.org \
--cc=qemu-devel@nongnu.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).