[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Re: [Qemu-devel] [PATCH] qemu and qemu-xen: support empty write barriers in xen_disk
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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |