On Thu, Sep 26, 2013 at 01:43:25PM +1000, Dave Chinner wrote: > 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. If the fs is using REQ_FUA for ordering they need to wait for completion of that bio before issuing any subsequent bio that needs to be strictly ordered. So I don't think there is any issue here. > 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. Yes, this is a valid concern, but I assume Akira has benchmarked. With dm-thin, I delay the REQ_FUA/REQ_FLUSH for a tiny amount, just to see if there are any other FUA requests on my queue that can be aggregated into a single flush. I agree with you that the target should never delay waiting for new io; that's asking for trouble. - Joe _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
