From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Hellwig Subject: Re: Re: [PATCH] xen block backend driver. Date: Thu, 21 Apr 2011 15:06:06 -0400 Message-ID: <20110421190606.GA10793@infradead.org> References: <1303333543-5915-1-git-send-email-konrad.wilk@oracle.com> <1303333543-5915-2-git-send-email-konrad.wilk@oracle.com> <20110421034016.GB11501@infradead.org> <1303412592.9571.126.camel@agari.van.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <1303412592.9571.126.camel@agari.van.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Daniel Stodden Cc: "xen-devel@lists.xensource.com" , Konrad Rzeszutek Wilk , "jaxboe@fusionio.com" , "linux-kernel@vger.kernel.org" , Christoph Hellwig , "konrad@kernel.org" List-Id: xen-devel@lists.xenproject.org On Thu, Apr 21, 2011 at 12:03:12PM -0700, Daniel Stodden wrote: > Yes, everybody is aware that the semantics were broken. But note it's > not even a consistency issue at this point, because there's currently no > frontend which relies on the original ordering semantics either. Take > xen-blkfront, since blk_flush it uses the barrier op for a flush, being > just a superset when ordering is enforced. There is a huge userbase of guests out there that does rely on it. > But before we just enumerate a new command, a potentially more viable > option would be FLUSH+FUA flags on the WRITE operation. As if mapping > bio bits. > > The advantage is that it avoids the extra round trip implied by having > the frontend driving writes through FSEQ_PREFLUSH on their own. I'd > expect that to make much more of a performance difference. Somewhat > differentiating PV from the low physical layer. > > Would you, maybe did you, consider that? I think it sounds interesting > enough to gather performance data, just asking beforehand. You will need a pure flush anyway. Once you actually have a correct implementation you can look into optimizing it. Note that at least the Solaris Xen coded added a cache flush to the protocol.