Re: [for-416 PATCH 3/3] bcache: allow quick writeback when backing idle

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux RAID]     [Linux SCSI]     [Linux ATA RAID]     [IDE]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Device Mapper]

  Powered by Linux