Hi Bart
Thanks for your kindly response.
On 04/20/2018 10:11 PM, Bart Van Assche wrote:
On Fri, 2018-04-20 at 14:55 +0800, jianchao.wang wrote:
Hi Bart
On 04/20/2018 12:43 AM, Bart Van Assche wrote:
Use the deadline instead of the request generation to detect whether or not a request timer fired after reinitialization of a request
Maybe use deadline to do this is not suitable.
Let's think of the following scenario.
T1/T2 times in nano seconds J1/J2 times in jiffies
rq is started at T1,J1 blk_mq_timeout_work -> blk_mq_check_expired -> save rq->__deadline (J1 + MQ_RQ_IN_FLIGHT)
rq is completed and freed rq is allocated and started again on T2 rq->__deadline = J2 + MQ_RQ_IN_FLIGHT-> synchronize srcu/rcu -> blk_mq_terminate_expired -> rq->__deadline (J2 + MQ_RQ_IN_FLIGHT)
deadline = rq->__deadline & ~RQ_STATE_MASK (0x3) if J2-J1 < 4 jiffies, we will get the same deadline value.
even if we do some bit shift when save and get deadline if T2 - T1 < time of 1 jiffies, we sill get the same deadline.
Hello Jianchao,
How about using the upper 16 or 32 bits of rq->__deadline to store a generation number? I don't know any block driver for which the product of (deadline in seconds) and HZ exceeds (1 << 32).
yes, we don't need so long timeout value. However, req->__deadline is an absolute time, not a relative one, its type is unsigned long variable which is same with jiffies. If we reserve some bits (not just 1 or 2 bits) of req->__deadline for generation number, how to handle it when mod_timer ?
Thanks Jianchao