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

[Kevin Wolf <kwolf@xxxxxxxxxx>]

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?

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.

Kevin

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