From: Tang Junhui <tang.junhui@xxxxxxxxxx> >I don't think so. The thing that is controlled (in current code, and >this patch set) is the rate of issuance, not of completion (though >issuance rate is guaranteed not to exceed completion rate, because of >the semaphore for the maximum number of I/Os outstanding). OK, I see. >The intention with this code is to notice when we are ahead on >schedule on writeback, and if so, start the next I/O after all of the >current set finishes. Only in this case do we do closure_sync, as a >way to wait for all the existing I/Os to complete. This guarantees >that we never have more than one I/O outstanding when doing >"opportunistic idle writeback", and that new front-end I/O never has >to compete with more than one thing in the queue in this case. If no front-end I/O coming, would this cause write-back IOs one by one (one write-back IO issued must after the completion of the previous IO)? though with zero delay time, is the write-back performance still good? Thanks, Tang Junhui -- To unsubscribe from this list: send the line "unsubscribe linux-bcache" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
