From: Tang Junhui <redacted>

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