From: Badari Pulavarty <pbadari@us.ibm.com>
To: Anthony Liguori <aliguori@us.ibm.com>
Cc: Kevin Wolf <kwolf@redhat.com>,
Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>,
Stefan Hajnoczi <stefanha@gmail.com>,
qemu-devel@nongnu.org, Khoa Huynh <khoa@us.ibm.com>,
pbadari@linux.vnet.ibm.com, Christoph Hellwig <hch@lst.de>
Subject: Re: [Qemu-devel] [PATCH] raw-posix: Linearize direct I/O on Linux NFS
Date: Fri, 15 Apr 2011 16:33:51 -0700 [thread overview]
Message-ID: <4DA8D5DF.5070503@us.ibm.com> (raw)
In-Reply-To: <4DA8CE00.3090907@us.ibm.com>
On 4/15/2011 4:00 PM, Anthony Liguori wrote:
> On 04/15/2011 05:21 PM, pbadari@linux.vnet.ibm.com wrote:
>> On 4/15/2011 10:29 AM, Christoph Hellwig wrote:
>>> On Fri, Apr 15, 2011 at 09:23:54AM -0700, Badari Pulavarty wrote:
>>>> True. That brings up a different question - whether we are doing
>>>> enough testing on mainline QEMU :(
>>> It seems you're clearly not doing enough testing on any qemu. Even
>>> the RHEL6 qemu has had preadv/pwritev since the first beta.
>>
>> Christoph,
>>
>> When you say "you're" - you really meant RH right ? RH should have
>> caught this in their
>> regression year ago as part of their first beta. Correct ?
>>
>> Unfortunately, you are picking on person who spent time find &
>> analyzing the regression,
>> narrowing the problem area and suggesting approaches to address the
>> issue :(
>
> This is a pretty silly discussion to be having.
>
> The facts are:
>
> 1) NFS sucks with preadv/pwritev and O_DIRECT -- is anyone really
> surprised?
>
> 2) We could work around this in QEMU by doing something ugly
>
> 3) We have no way to detect when we no longer need a work around which
> makes (2) really unappealing.
>
> 4) That leaves us with:
> a) waiting for NFS to get fixed properly and just living with
> worse performance on older kernels
>
> b) having a user-tunable switch to enable bouncing
>
> I really dislike the idea of (b) because we're stuck with it forever
> and it's yet another switch for people to mistakenly depend on.
>
> I'm still waiting to see performance data without O_DIRECT. I suspect
> that using cache=writethrough will make most of this problem go away
> in which case, we can just recommend that as a work around until NFS
> is properly fixed.
We need to run through all cases and analyze the performance of
cache=writethrough. Our initial (smaller setup) analysis
indicates that its better than unpatched O_DIRECT - but ~5% slower for
sequential writes. But 30%+ slower for
random read/writes and mixed IO workloads. (In the past NFS O_SYNC is
performance extremely poor compared to
O_DIRECT with no scaling - older kernels due to congestion control issues).
Khoa would collect the data over next few days.
To be honest with you, we should kill cache=none and just optimize only
one case and live with it (like other commerical
hypervisor). :(
Thanks,
Badari
next prev parent reply other threads:[~2011-04-15 23:33 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-15 13:40 [Qemu-devel] [PATCH] raw-posix: Linearize direct I/O on Linux NFS Stefan Hajnoczi
2011-04-15 15:05 ` Christoph Hellwig
2011-04-15 15:26 ` Stefan Hajnoczi
2011-04-15 15:34 ` Christoph Hellwig
2011-04-15 16:10 ` Anthony Liguori
2011-04-15 16:17 ` Stefan Hajnoczi
2011-04-15 17:27 ` Christoph Hellwig
2011-04-15 16:23 ` Badari Pulavarty
2011-04-15 17:29 ` Christoph Hellwig
2011-04-15 22:21 ` Badari Pulavarty
2011-04-15 23:00 ` Anthony Liguori
2011-04-15 23:33 ` Badari Pulavarty [this message]
2011-04-16 2:05 ` Christoph Hellwig
2011-04-16 8:46 ` Stefan Hajnoczi
2011-04-16 2:03 ` Christoph Hellwig
2011-04-15 18:09 ` Anthony Liguori
2011-04-15 18:25 ` Badari Pulavarty
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=4DA8D5DF.5070503@us.ibm.com \
--to=pbadari@us.ibm.com \
--cc=aliguori@us.ibm.com \
--cc=hch@lst.de \
--cc=khoa@us.ibm.com \
--cc=kwolf@redhat.com \
--cc=pbadari@linux.vnet.ibm.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@gmail.com \
--cc=stefanha@linux.vnet.ibm.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 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).