Re: [Xen-devel] Re: [Qemu-devel] [PATCH] qemu and qemu-xen: support empty write barriers in xen_disk

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

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