On Tue, Sep 24, 2013 at 09:20:50PM +0900, Akira Hayakawa wrote: > * Deferring ACK for barrier writes > Barrier flags such as REQ_FUA and REQ_FLUSH are handled lazily. > Immediately handling these bios badly slows down writeboost. > It surveils the bios with these flags and forcefully flushes them > at worst case within `barrier_deadline_ms` period. That rings alarm bells. If the filesystem is using REQ_FUA/REQ_FLUSH for ordering reasons, delaying them to allow other IOs to be submitted and dispatched may very well violate the IO ordering constraints the filesystem is trying to acheive. Alternatively, delaying them will stall the filesystem because it's waiting for said REQ_FUA IO to complete. For example, journal writes in XFS are extremely IO latency sensitive in workloads that have a signifincant number of ordering constraints (e.g. O_SYNC writes, fsync, etc) and delaying even one REQ_FUA/REQ_FLUSH can stall the filesystem for the majority of that barrier_deadline_ms. i.e. this says to me that the best performance you can get from such workloas is one synchronous operation per process per barrier_deadline_ms, even when the storage and filesystem might be capable of executing hundreds of synchronous operations per barrier_deadline_ms.. Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
