On 12/14/21 7:59 AM, Jens Axboe wrote:
On 12/14/21 8:04 AM, Christoph Hellwig wrote:
So why not do a non-delayed queue_work for that case? Might be good
to get the scsi and workqueue maintaines involved to understand the
issue a bit better first.
We can probably get by with doing just that, and just ignore if a delayed
work timer is already running.
Dexuan, can you try this one?
diff --git a/block/blk-core.c b/block/blk-core.c
index 1378d084c770..c1833f95cb97 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -1484,6 +1484,8 @@ EXPORT_SYMBOL(kblockd_schedule_work);
int kblockd_mod_delayed_work_on(int cpu, struct delayed_work *dwork,
unsigned long delay)
{
+ if (!delay)
+ return queue_work_on(cpu, kblockd_workqueue, &dwork->work);
return mod_delayed_work_on(cpu, kblockd_workqueue, dwork, delay);
}
EXPORT_SYMBOL(kblockd_mod_delayed_work_on);
As Christoph already mentioned, it would be great to receive feedback from the
workqueue maintainer about this patch since I'm not aware of other kernel code
that queues delayed_work in a similar way.
Regarding the feedback from the view of the SCSI subsystem: I'd like to see the
block layer core track whether or not a queue needs to be run such that the
scsi_run_queue_async() call can be removed from scsi_end_request(). No such call
was present in the original conversion of the SCSI core from the legacy block
layer to blk-mq. See also commit d285203cf647 ("scsi: add support for a blk-mq
based I/O path.").
Bart.
