On 04/21/2018 10:10 PM, Jens Axboe wrote:
> On 4/21/18 7:34 AM, jianchao.wang wrote:
>> 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)
>>>>
>>>> 1. deadline = rq->__deadline & ~RQ_STATE_MASK (0x3)
>>>> if J2-J1 < 4 jiffies, we will get the same deadline value.
>>>>
>>>> 2. 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 ?
>
> We don't need to support timeouts to the full granularity of jiffies.
> Most normal commands are in the 30-60s range, and some lower level
> commands may take minutes. We're well within the range of chopping
> off some bits and not having to worry about that at all.
>
Yes.
So we have a __deadline as below:
deadline gen state
|______________|____|_|
\___ __/
V
granularity
and even we usually have a 30~60s timeout,
but we should support a 1s granularity at least.
How to decide the granularity ?
Thanks
Jianchao
