qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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

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