Re: FLUSH mechanism implementation in block layer

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Tejun

Thank you for the detailed explanation!

Best Regards
Tanya Brokhman
--
QUALCOMM ISRAEL, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

On 4/9/2013 10:03 PM, Tejun Heo wrote:
Hey,

On Mon, Apr 08, 2013 at 07:19:19AM +0300, Tanya Brokhman wrote:
completed after the FLUSH. But perhaps there is a correct way to
move the implementation of "ordering around the flush" to the block
layer? Not that it would work better, it just feels that logically -
block layer is the place to do it at.
What do you think?

It used to be implemented that way - REQ_BARRIER.  The problem was
that filesystems wanted multiple dependency streams - ie. fdatasync()
of a file doesn't need to drain all other IOs in progress.  We could
do coloring of IOs - ie. give IOs which may need flushing later but
belong to different dependency streams different colors and let block
layer figure out partial drainining, which would work but at the same
time be pretty nasty and complex.  The thing was that most filesystems
were already drainings IOs and didn't need any ordering guarantee from
block layer.  hch took care of the outliers which were depending on
REQ_BARRIER ordering guarantees and we just stripped the ordering
mechanism which immediately improved performance noticeably in certain
workloads.

It was done that way mostly out of convenience at that time but now I
think of it it's the correct thing to do.  It just is too much
information to communicate downwards and the extra communication
overhead doesn't really buy anything.

Thanks.




--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux USB Devel]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux