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 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.