Re: [PATCH v2] block: reduce kblockd_mod_delayed_work_on() CPU consumption

[John Garry <john.garry@huawei.com>]

On 15/12/2021 15:47, Jens Axboe wrote:
>> 0000000000001ef0 <__blk_mq_delay_run_hw_queue>:
>>       [snip]
>>       2024: a942dfb6 ldp x22, x23, [x29, #40]
>>       2028: 2a1503e0 mov w0, w21
>>       202c: 94000000 bl 0 <__msecs_to_jiffies>
>> kblockd_mod_delayed_work_on(blk_mq_hctx_next_cpu(hctx), &hctx->run_work,
>>       2030: aa0003e2 mov x2, x0
>>       2034: 91010261 add x1, x19, #0x40
>>       2038: 2a1403e0 mov w0, w20
>>       203c: 94000000 bl 0 <kblockd_mod_delayed_work_on>
>>
>> I'm not sure if you would want to change so many APIs or if jiffies is
>> sensible to pass or even any performance gain. Additionally Function
>> blk_mq_delay_kick_requeue_list() would not see so much gain in such a
>> change as msec value is not const. Any thoughts? Maybe testing
>> performance would not do much harm.
> In general I totally agree with you, it'd be smarter to flip the
> conversion so it can be done in a more efficient manner.


> At the same
> time, the queue delay running is not at all a fast path, so shouldn't
> really matter in practice.

ok, I just thought that from checking your change that we have a 
frequent msec_to_jiffies(0 [non const]) call in 
__blk_mq_delay_run_hw_queue() -> kblockd_mod_delayed_work_on().

Thanks,
John