Hi Tejun, On Tue, Jul 18, 2023 at 1:03 AM Tejun Heo <tj@xxxxxxxxxx> wrote: > Can you please the following patch and see how many reports you get? Looking > back at your reports, I think some of them probably should be converted to > UNBOUND but we should have a better idea with the adjusted threshold. > > Thanks. > > From 8555cbd4b22e5f85eb2bdcb84fd1d1f519a0a0d3 Mon Sep 17 00:00:00 2001 > From: Tejun Heo <tj@xxxxxxxxxx> > Date: Mon, 17 Jul 2023 12:50:02 -1000 > Subject: [PATCH] workqueue: Scale up wq_cpu_intensive_thresh_us if BogoMIPS is > below 1000 > > 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 1000. 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@xxxxxxxxxx> Thanks! I gave it a try on a system with an 800 MHz Cortex A9, only to discover it makes no difference, as that machine has 1600 BogoMIPS: workqueue: drm_fb_helper_damage_work hogged CPU for >10000us 4 times, consider switching to WQ_UNBOUND workqueue: drm_fb_helper_damage_work hogged CPU for >10000us 8 times, consider switching to WQ_UNBOUND workqueue: genpd_power_off_work_fn hogged CPU for >10000us 4 times, consider switching to WQ_UNBOUND workqueue: blk_mq_run_work_fn hogged CPU for >10000us 4 times, consider switching to WQ_UNBOUND workqueue: pm_runtime_work hogged CPU for >10000us 4 times, consider switching to WQ_UNBOUND workqueue: phy_state_machine hogged CPU for >10000us 4 times, consider switching to WQ_UNBOUND workqueue: drm_mode_rmfb_work_fn hogged CPU for >10000us 4 times, consider switching to WQ_UNBOUND workqueue: sync_hw_clock hogged CPU for >10000us 4 times, consider switching to WQ_UNBOUND workqueue: rtc_timer_do_work hogged CPU for >10000us 4 times, consider switching to WQ_UNBOUND Artificially low BogoMIPS numbers only happen on systems that have the related timers (Cortex A7/A15 and later, Cortex A9 MPCore, and arm64). I will test on more systems, but that will probably not happen until next week... Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds