Hey, On Tue, Apr 26, 2011 at 08:46:30AM +0800, Shaohua Li wrote: > the blk-flush is part of block layer. If what you mean is the libata > part, block layer doesn't know if flush is queueable without knowledge > from driver. It seems my communication skill towards you sucks badly. I was talking about making both the issue and completion paths cooperate on flush sequence handling instead of depending on queuability of flush to make assumptions on completion order, which I still think is incorrect. > > Also, another interesting thing to investigate is why the two flushes > > didn't get merged in the first place. The two flushes apparently > > didn't have any ordering requirement between them. Why didn't they > > get merged in the first place? If the first flush were slightly > > delayed, the second would have been issued together from the beginning > > and we wouldn't have to think about merging them afterwards. Maybe > > what we really need is better algorithm than C1/2/3 described in the > > comment? > > the sysbench fileio does a 16 threads write-fsync, so it's quite normal > a flush is running and another flush is added into pending list. I think you're optimizing in the wrong place. These back-to-back flushes better be merged on the issue side instead of completion. The current merging rules (basically how long to delay pending flushes) are minimal and mechanical (timeout is the only huristic parameter). For the initial implementation, my goal was matching the numbers of Darrick's original implementation at higher level and keeping things simple, but the code is intentionally structured to allow easy tuning of merging criteria, so I suggest looking there instead of mucking with completion path. Thank you. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
