On 04/10/2017 01:12 AM, Christoph Hellwig wrote: >> + if (msecs == 0) >> + kblockd_schedule_work_on(blk_mq_hctx_next_cpu(hctx), >> + &hctx->run_work); >> + else >> + kblockd_schedule_delayed_work_on(blk_mq_hctx_next_cpu(hctx), >> + &hctx->delayed_run_work, >> + msecs_to_jiffies(msecs)); >> +} > > I'd rather make run_work a delayed_work (again) and use > kblockd_schedule_delayed_work_on with a timeout of zero for the immediate > run case instead of having two competing work structs.
Yeah that's a good point, it'd have to be an incremental patch at this point though. Also note that blk_mq_stop_hw_queue() isn't currently canceling the new ->delayed_run_work, that looks like a bug. And looking at it, right now we have 3 (three!) work items in the hardware queue. The two delayed items differ in that one of them only runs the queue it was previously stopped, that's it. The non-delayed one is identical to the non stopped checking delayed variant. I'll send out a patch. -- Jens Axboe
