On Mon, Aug 02, 2010 at 02:28:04PM -0400, Vivek Goyal wrote: > Hi Christoph, > > Please find attached a new version of patch where I am trying to implement > flush only barriers. Why do that? I was thinking that it would nice to avoid > elevator drains with WCE=1. > > Here I have a DRAIN queue and I seem to be issuing post-flush only after > barrier has finished. Need to find some device with TAG queue also to test. > > This is still a very crude patch where I need to do lot of testing to see if > things are working. For the time being I have just hooked up ext3 to use > flush barrier and verified that in case of WCE=0 we don't issue barrier > and in case of WCE=1 we do issue barrier with pre flush and postflush. > > I don't yet have found a device with FUA and tagging support to verify > that functionality. There are not devices that use the tagging support. Only brd and virtio every use the QUEUE_ORDERED_TAG type. For brd Nick chose it at random, and it really doesn't matter when we're dealing with a ramdisk. For virtio-blk it's only used by lguest which only allows a signle outstanding command anyway. In short we can just remove it once we stop draining for the other modes. > o On storage with write cache, for empty barrier, only pre-flush is done. > For barrier request with some data one of following should happen depending > on queue capability. > > Draining queue > -------------- > preflush ==> barrier (FUA) > preflush ==> barrier ===> postflush > > Ordered Queue > ------------- > preflush-->barrier (FUA) > preflush --> barrier ---> postflush > > ===> Wait for previous request to finish > ---> Issue an ordered request in Tagged queue. with ordered you mean the unused _TAG mode? > - Not sure how to avoid this drain. Trying to allow other non-barrier > requests to dispatch while we wait for pre-flush/flush barrier to finish > will make code more complicated. That's pretty much where I got stuck, too. Thanks for doing this, but I'd be surprised if it really gives us all that much benefits for real life workloads. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
