Hi bart
On 05/11/2018 11:29 PM, Bart Van Assche wrote:
> On Fri, 2018-05-11 at 14:35 +0200, Christoph Hellwig wrote:
>>> It should be due to union blk_deadline_and_state.
>>> +union blk_deadline_and_state {
>>> + struct {
>>> + uint32_t generation:30;
>>> + uint32_t state:2;
>>> + uint32_t deadline;
>>> + };
>>> + unsigned long legacy_deadline;
>>> + uint64_t das;
>>> +};
>>
>> Yikes. Or we just move it into a separate field. This patch already
>> shrinks struct request a lot, so I'd rather do that to keep it simple.
>
> Hello Christoph,
>
> Are you perhaps referring to the legacy_deadline field? Have you noticed that
> Jianchao used a legacy block layer function in blk-mq code and that that is
> why a wrong value for the deadline appeared in the trace output?
>
I use blk_rq_deadline because __blk_add_timer uses it.
-
/*
* If the timer isn't already pending or this timeout is earlier
* than an existing one, modify the timer. Round up to next nearest
* second.
*/
expiry = blk_rq_timeout(round_jiffies_up(blk_rq_deadline(req)));
-
if (!timer_pending(&q->timeout) ||
time_before(expiry, q->timeout.expires)) {
unsigned long diff = q->timeout.expires - expiry;
This is also the reason why there is no issue about timeout when test.
blk_rq_timeout will return reasonable value.
In addition, on a 64bit system, how do you set up the timer with a 32bit deadline ?
Thanks
Jianchao
