On Thu, Apr 30, 2026 at 11:08:10AM +0200, Marco Crivellari wrote:
> Currently the code enqueue work items using {queue|mod}_delayed_work(),
> using system_long_wq. This workqueue should be used when long works are
> expected, but it is a per-cpu workqueue.
> 
> This is important because queue_delayed_work() queue the work using:
> 
>    queue_delayed_work_on(WORK_CPU_UNBOUND, ...);
> 
> Note that WORK_CPU_UNBOUND = NR_CPUS.
> 
> This would end up calling __queue_delayed_work() that does:
> 
>     if (housekeeping_enabled(HK_TYPE_TIMER)) {
>     //      [....]
>     } else {
>             if (likely(cpu == WORK_CPU_UNBOUND))
>                     add_timer_global(timer);
>             else
>                     add_timer_on(timer, cpu);
>     }
> 
> So when cpu == WORK_CPU_UNBOUND the timer is global and is
> not using a specific CPU. Later, when __queue_work() is called:
> 
>     if (req_cpu == WORK_CPU_UNBOUND) {
>             if (wq->flags & WQ_UNBOUND)
>                     cpu = wq_select_unbound_cpu(raw_smp_processor_id());
>             else
>                     cpu = raw_smp_processor_id();
>     }
> 
> Because the wq is not unbound, it takes the CPU where the timer
> fired and enqueue the work on that CPU.
> The consequence of all of this is that the work can run anywhere,
> depending on where the timer fired.
> 
> Recently, a new unbound workqueue specific for long running work has
> been added:
> 
>     c116737e972e ("workqueue: Add system_dfl_long_wq for long unbound works")
> 
> So change system_long_wq with system_dfl_long_wq so that the work may
> benefit from scheduler task placement.
> 
> Signed-off-by: Marco Crivellari <marco.crivellari@suse.com>

Looks very reasonable to me. With your detailed explanation, we could
probably also remove the FIXME next to the workqueue.h-include. This
seems to be the proper workqueue now. I will fix it when applying.

Thank you!