From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vladislav Bolkhovitin Subject: Re: [RFC] relaxed barrier semantics Date: Fri, 30 Jul 2010 16:46:12 +0400 Message-ID: <4C52C994.2040405@vlnb.net> References: <20100728085048.GA8884@lst.de> <4C4FF136.5000205@kernel.org> <20100728090025.GA9252@lst.de> <4C4FF592.9090800@kernel.org> <20100728092859.GA11096@lst.de> <20100729014431.GD4506@thunk.org> <4C51DA1F.2040701@redhat.com> <20100729194904.GA17098@lst.de> <4C51DCF1.3010507@redhat.com> <1280433591.4441.393.camel@mulgrave.site> <20100729200327.GA17767@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: James Bottomley , Ric Wheeler , Ted Ts'o , Tejun Heo , Vivek Goyal , Jan Kara , jaxboe@fusionio.com, linux-fsdevel@vger.kernel.org, linux-scsi@vger.kernel.org, chris.mason@oracle.com, swhiteho@redhat.com, konishi.ryusuke@lab.ntt.co.jp To: Christoph Hellwig Return-path: In-Reply-To: <20100729200327.GA17767@lst.de> Sender: linux-scsi-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org Christoph Hellwig, on 07/30/2010 12:03 AM wrote: > On Thu, Jul 29, 2010 at 02:59:51PM -0500, James Bottomley wrote: >> That's basically everything FUA ... you might just as well switch your >> cache to write through and have done. >> >> This, by the way, is one area I'm hoping to have researched on SCSI >> (where most devices do obey the caching directives). Actually see if >> write through without flush barriers is faster than writeback with flush >> barriers. I really suspect it is. > > We have done the research and at least for XFS a write through cache > actually is faster for many workloads. Ric always has workloads where > the cache is faster, though - mostly doing lots of small file write > kind of setups. I supposed, with write back cache you did the queue drain after request(s) with ordered requirements, correct? Did you also do the queue drain in the same places with write through caching? Just in case, to be sure the comparison was fair. I can't see why sequence of [(write command/internal cache sync) .. (write command/internal cache sync)] for write through caching should be faster than sequence of [(write command) .. (write command) (cache sync) .. (write command) .. (write command) (cache sync)], except if there are additional queue flushing (draining) in the latter case. I think we need to explain that before doing the next step. Vlad