On Thu, 2018-12-06 at 22:18 +-0800, Weiping Zhang wrote: +AD4 Before this patch, even we set io+AF8-timeout to 30+ACo-HZ(default), but +AD4 blk+AF8-rq+AF8-timeout always return jiffies +-5+ACo-HZ, +AD4 +AFs-1+AF0. if there no pending request in timeout list, the timer callback +AD4 blk+AF8-rq+AF8-timed+AF8-out+AF8-timer will be called after 5+ACo-HZ, and then +AD4 blk+AF8-mq+AF8-check+AF8-expired will check is there exist some request +AD4 was delayed by compare jiffies and request-+AD4-deadline, obvious +AD4 request is not timeout because we set request's timeouts is 30+ACo-HZ. +AD4 So for this case timer callback should be called at jiffies +- 30 instead +AD4 of jiffies +- 5+ACo-HZ. +AD4 +AD4 +AFs-2+AF0. if there are pending request in timeout list, we compare request's +AD4 expiry and queue's expiry. If time+AF8-after(request-+AD4-expire, queue-+AD4-expire) modify +AD4 queue-+AD4-timeout.expire to request-+AD4-expire, otherwise do nothing. +AD4 +AD4 So I think this patch just solve problem in +AFs-1+AF0, no other regression, or what's +AD4 I missing here ? The blk+AF8-rq+AF8-timeout() function was introduced by commit 0d2602ca30e4 (+ACI-blk-mq: improve support for shared tags maps+ACI). I think the purpose of that function is to make sure that the nr+AF8-active counter in struct blk+AF8-mq+AF8-hw+AF8-ctx gets updated at least once every five seconds. So there are two problems with this patch: - It reduces the frequency of 'nr+AF8-active' updates. I think that is wrong and also that it will negatively affect drivers that rely on this functionality, e.g. the SCSI core. - The patch description does not match the code changes in this patch. Bart.
