From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=56298 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PLKKG-0004Q9-Ox for qemu-devel@nongnu.org; Wed, 24 Nov 2010 13:44:18 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PLKKE-0006Zg-EF for qemu-devel@nongnu.org; Wed, 24 Nov 2010 13:44:16 -0500 Received: from verein.lst.de ([213.95.11.210]:59468) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PLKKE-0006Yz-54 for qemu-devel@nongnu.org; Wed, 24 Nov 2010 13:44:14 -0500 Date: Wed, 24 Nov 2010 19:44:05 +0100 From: Christoph Hellwig Subject: Re: [Xen-devel] Re: [Qemu-devel] [PATCH] qemu and qemu-xen: support empty write barriers in xen_disk Message-ID: <20101124184405.GA2406@lst.de> References: <20101124165835.GF31124@lst.de> <4CED5700.9070204@goop.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CED5700.9070204@goop.org> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jeremy Fitzhardinge Cc: qemu-devel@nongnu.org, xen-devel@lists.xensource.com, Christoph Hellwig , Stefano Stabellini 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. > > J ---end quoted text---