On 12/21/21 8:35 AM, Michael Kelley (LINUX) wrote: > From: Sasha Levin <sashal@xxxxxxxxxx> Sent: Monday, December 20, 2021 5:58 PM >> >> From: Jens Axboe <axboe@xxxxxxxxx> >> >> [ Upstream commit cb2ac2912a9ca7d3d26291c511939a41361d2d83 ] >> >> Dexuan reports that he's seeing spikes of very heavy CPU utilization when >> running 24 disks and using the 'none' scheduler. This happens off the >> sched restart path, because SCSI requires the queue to be restarted async, >> and hence we're hammering on mod_delayed_work_on() to ensure that the work >> item gets run appropriately. >> >> Avoid hammering on the timer and just use queue_work_on() if no delay >> has been specified. >> >> Reported-and-tested-by: Dexuan Cui <decui@xxxxxxxxxxxxx> >> Link: https://lore.kernel.org/linux-block/BYAPR21MB1270C598ED214C0490F47400BF719@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/ >> Reviewed-by: Ming Lei <ming.lei@xxxxxxxxxx> >> Signed-off-by: Jens Axboe <axboe@xxxxxxxxx> >> Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx> >> --- >> block/blk-core.c | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/block/blk-core.c b/block/blk-core.c >> index c2d912d0c976c..a728434fcff87 100644 >> --- a/block/blk-core.c >> +++ b/block/blk-core.c >> @@ -1625,6 +1625,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); >> -- >> 2.34.1 > > Sasha -- there are reports of this patch causing performance problems. > See > https://lore.kernel.org/lkml/1639853092.524jxfaem2.none@localhost/. I > would suggest *not* backporting it to any of the stable branches until > the issues are fully sorted out. Both this and the revert were backported. Which arguably doesn't make a lot of sense, but at least it's consistent and won't cause any issues... -- Jens Axboe
