Re: [PATCH] mark power efficient workqueue as unbounded if nohz_full enabled

From: Marcelo Tosatti
Date: Mon Jan 22 2024 - 09:28:06 EST


On Fri, Jan 19, 2024 at 01:57:48PM -1000, Tejun Heo wrote:
> On Fri, Jan 19, 2024 at 12:54:39PM -0300, Marcelo Tosatti wrote:
> >
> > A customer using nohz_full has experienced the following interruption:
> >
> > oslat-1004510 [018] timer_cancel: timer=0xffff90a7ca663cf8
> > oslat-1004510 [018] timer_expire_entry: timer=0xffff90a7ca663cf8 function=delayed_work_timer_fn now=4709188240 baseclk=4709188240
> > oslat-1004510 [018] workqueue_queue_work: work struct=0xffff90a7ca663cd8 function=fb_flashcursor workqueue=events_power_efficient req_cpu=8192 cpu=18
> > oslat-1004510 [018] workqueue_activate_work: work struct 0xffff90a7ca663cd8
> > oslat-1004510 [018] sched_wakeup: kworker/18:1:326 [120] CPU:018
> > oslat-1004510 [018] timer_expire_exit: timer=0xffff90a7ca663cf8
> > oslat-1004510 [018] irq_work_entry: vector=246
> > oslat-1004510 [018] irq_work_exit: vector=246
> > oslat-1004510 [018] tick_stop: success=0 dependency=SCHED
> > oslat-1004510 [018] hrtimer_start: hrtimer=0xffff90a70009cb00 function=tick_sched_timer/0x0 ...
> > oslat-1004510 [018] softirq_exit: vec=1 [action=TIMER]
> > oslat-1004510 [018] softirq_entry: vec=7 [action=SCHED]
> > oslat-1004510 [018] softirq_exit: vec=7 [action=SCHED]
> > oslat-1004510 [018] tick_stop: success=0 dependency=SCHED
> > oslat-1004510 [018] sched_switch: oslat:1004510 [120] R ==> kworker/18:1:326 [120]
> > kworker/18:1-326 [018] workqueue_execute_start: work struct 0xffff90a7ca663cd8: function fb_flashcursor
> > kworker/18:1-326 [018] workqueue_queue_work: work struct=0xffff9078f119eed0 function=drm_fb_helper_damage_work workqueue=events req_cpu=8192 cpu=18
> > kworker/18:1-326 [018] workqueue_activate_work: work struct 0xffff9078f119eed0
> > kworker/18:1-326 [018] timer_start: timer=0xffff90a7ca663cf8 function=delayed_work_timer_fn ...
> >
> > Set wq_power_efficient to true, in case nohz_full is enabled.
> > This makes the power efficient workqueue be unbounded, which allows
> > workqueue items there to be moved to HK CPUs.
> >
> > Signed-off-by: Marcelo Tosatti <mtosatti@xxxxxxxxxx>
>
> Applied to wq/for-6.9.
>
> A side note: with the recent affinity improvements to unbound workqueues, I
> wonder whether we'd be able to drop wq_power_efficient and just use
> system_unbound_wq instead without noticeable perf difference.
>
> Thanks.
>
> --
> tejun

Tejun,

About the performance difference (of running locally VS running
remotely), can you list a few performance sensitive work queues
(where per-CPU execution makes a significant difference).

Because i suppose it would be safe (from a performance regression
perspective) to move all delayed works to housekeeping CPUs.

And also, being more extreme, why not an option to mark all workqueues
as unbounded (or perhaps userspace control of bounding, even for
workqueues marked as "per-CPU").

Thanks.