From mboxrd@z Thu Jan  1 00:00:00 1970
From: Christoph Hellwig <hch@lst.de>
Subject: Re: sync guest calls made async on host - SQLite performance
Date: Wed, 14 Oct 2009 15:41:22 +0200
Message-ID: <20091014134122.GA14235@lst.de>
References: <d9c105ea0910071159o7a4e475btfaebdbfec66b9deb@mail.gmail.com> <4ACCEC9F.7090309@gmail.com> <4ACE0196.9010904@gmail.com> <d9c105ea0910082312n7218e1abhc69a2be660838e89@mail.gmail.com> <f28b49ce0910090425p385636c3he6dfb7595927d7e4@mail.gmail.com> <d9c105ea0910090818m16dd7c49pbd15c8123fdc2bea@mail.gmail.com> <4ACF89CB.5020406@gmail.com> <4AD1A27A.4060307@redhat.com> <20091013223714.GB16152@lst.de> <4AD5B00D.102@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: Christoph Hellwig <hch@lst.de>,
	Matthew Tippett <tippettm@gmail.com>,
	Dustin Kirkland <dustin.kirkland@gmail.com>,
	Anthony Liguori <anthony@codemonkey.ws>, RW <kvm@tauceti.net>,
	kvm@vger.kernel.org
To: Avi Kivity <avi@redhat.com>
Return-path: <kvm-owner@vger.kernel.org>
Received: from verein.lst.de ([213.95.11.210]:60608 "EHLO verein.lst.de"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1761807AbZJNNmN (ORCPT <rfc822;kvm@vger.kernel.org>);
	Wed, 14 Oct 2009 09:42:13 -0400
Content-Disposition: inline
In-Reply-To: <4AD5B00D.102@redhat.com>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

On Wed, Oct 14, 2009 at 08:03:41PM +0900, Avi Kivity wrote:
> >Can't remember anything like that.  The "bug" was the complete lack of
> >cache flush infrastructure for virtio, and the lack of advertising a
> >volative write cache on ide.
> >   
> 
> By "complete flush infrastructure", you mean host-side and guest-side 
> support for a new barrier command, yes?

The cache flush command, not barrier command.  The new virtio code
implements barrier the same way we do for IDE and SCSI - all barrier
semantics are implemented by generic code in the block layer by draining
the queues, the only thing we send over the wire are cache flush
commands in strategic places.

> But can't this be also implemented using QUEUE_ORDERED_DRAIN, and on the 
> host side disabling the backing device write cache?  I'm talking about 
> cache=none, primarily.

Yes, it could.  But as I found out in a long discussion with Stephen
it's not actually nessecary.  All filesystems do the right thing for
a device not claiming to support barriers if it doesn't include write
caches, that is implement ordering internally.  So there is no urge to
set QUEUE_ORDERED_DRAIN for the case without write cache.