WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] Re: [Qemu-devel] [PATCH] qemu and qemu-xen: support empt

To: Kevin Wolf <kwolf@xxxxxxxxxx>
Subject: Re: [Xen-devel] Re: [Qemu-devel] [PATCH] qemu and qemu-xen: support empty write barriers in xen_disk
From: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
Date: Fri, 26 Nov 2010 15:25:19 +0000
Cc: Jeremy Fitzhardinge <jeremy@xxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Stabellini <Stefano.Stabellini@xxxxxxxxxxxxx>, "qemu-devel@xxxxxxxxxx" <qemu-devel@xxxxxxxxxx>, Stefano, Christoph Hellwig <hch@xxxxxx>
Delivery-date: Fri, 26 Nov 2010 07:26:15 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4CEF9407.80706@xxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <alpine.DEB.2.00.1011241305080.2373@kaball-desktop> <20101124165835.GF31124@xxxxxx> <4CED5700.9070204@xxxxxxxx> <20101124184405.GA2406@xxxxxx> <4CEF9407.80706@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Alpine 2.00 (DEB 1167 2008-08-23)
On Fri, 26 Nov 2010, Kevin Wolf wrote:
> Am 24.11.2010 19:44, schrieb Christoph Hellwig:
> > On Wed, Nov 24, 2010 at 10:18:40AM -0800, Jeremy Fitzhardinge wrote:
> >> Linux wants is a useful thing to do and implement (especially since it
> >> amounts to standardising the ?BSD extension).  I'm not sure of their
> >> precise semantics (esp WRT ordering), but I think its already OK.
> > 
> > The nice bit is that a pure flush does not imply any odering at all.
> > Which is how the current qemu driver implements the barrier requests
> > anyway, so that needs some fixing.
> > 
> >> (BTW, in case it wasn't clear, we're seriously considering - but not yet
> >> committed to - using qemu as the primary PV block backend for Xen
> >> instead of submitting the existing blkback code for upstream.  We still
> >> need to do some proper testing and measuring to make sure it stacks up
> >> OK, and work out how it would fit together with the rest of the
> >> management stack.  But so far it looks promising.)
> > 
> > Good to know.  Besides the issue with barriers mentioned above there's
> > a few things that need addressing in xen_disk, if you (or Stefano or
> > Daniel) are interested:
> > 
> >  - remove the syncwrite tunable, as this is handled by the underlying
> >    posix I/O code if needed by using O_DSYNC which is a lot more
> >    efficient.
> >  - check whatever the issue with the use_aio codepath is and make it
> >    the default.  It should help the performance a lot.
> >  - Make sure to use bdrv_aio_flush for cache flushes in the aio
> >    codepath, currently it still uses plain synchronous flushes.
> 
> I don't think the synchronous flushes even do what they're supposed to
> do. Shouldn't ioreq->postsync do the flush after the request has
> completed instead of doing it as soon as it has been submitted?
> 

I noticed that, it is one of the reasons I disabled aio for xen_disk in
qemu-xen. That and the fact that the aio implementation in qemu-xen is
still thread based. In fact I am waiting for Xen support to be in
upstream qemu before doing any benchmarks, because I expect the
performances to be better.

> Let alone that, as you mentioned above, it doesn't implement barrier
> semantics at all.
> 
> Oh, and it would be very nice if the return values of
> bdrv_aio_readv/writev and bdrv_flush were checked. They can return errors.
 
Indeed, my todo list is growing...


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>