OSDN Git Service

workqueue: Scale up wq_cpu_intensive_thresh_us if BogoMIPS is below 4000
authorTejun Heo <tj@kernel.org>
Mon, 17 Jul 2023 22:50:02 +0000 (12:50 -1000)
committerTejun Heo <tj@kernel.org>
Tue, 25 Jul 2023 21:49:57 +0000 (11:49 -1000)
commitaa6fde93f3a49e42c0fe0490d7f3711bac0d162e
treea916ed25852e11a874995004e1a5c8bc468ab461
parentb2ec116aad38aa9c8b67fad4314e50823adf6949
workqueue: Scale up wq_cpu_intensive_thresh_us if BogoMIPS is below 4000

wq_cpu_intensive_thresh_us is used to detect CPU-hogging per-cpu work items.
Once detected, they're excluded from concurrency management to prevent them
from blocking other per-cpu work items. If CONFIG_WQ_CPU_INTENSIVE_REPORT is
enabled, repeat offenders are also reported so that the code can be updated.

The default threshold is 10ms which is long enough to do fair bit of work on
modern CPUs while short enough to be usually not noticeable. This
unfortunately leads to a lot of, arguable spurious, detections on very slow
CPUs. Using the same threshold across CPUs whose performance levels may be
apart by multiple levels of magnitude doesn't make whole lot of sense.

This patch scales up wq_cpu_intensive_thresh_us upto 1 second when BogoMIPS
is below 4000. This is obviously very inaccurate but it doesn't have to be
accurate to be useful. The mechanism is still useful when the threshold is
fully scaled up and the benefits of reports are usually shared with everyone
regardless of who's reporting, so as long as there are sufficient number of
fast machines reporting, we don't lose much.

Some (or is it all?) ARM CPUs systemtically report significantly lower
BogoMIPS. While this doesn't break anything, given how widespread ARM CPUs
are, it's at least a missed opportunity and it probably would be a good idea
to teach workqueue about it.

Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-and-Tested-by: Geert Uytterhoeven <geert@linux-m68k.org>
kernel/workqueue.c