Re: [PATCH v3 net-next 0/6] net: Move system_long_wq to system_dfl_long_wq

[Marco Crivellari]

Hi,

On Tue, Jul 21, 2026 at 12:35 AM Jacob Keller <jacob.e.keller@xxxxxxxxx> wrote:
> [...]
> > system_long_wq is a per-cpu workqueue and it is used as a parameter of
> > queue_delayed_work(). This function schedule an item that it will later
> > be enqueued (once the timer will fire). __queue_delayed_work() does the job
> > receiving as "cpu" WORK_CPU_UNBOUND:
> >
> >     if (housekeeping_enabled(HK_TYPE_TIMER)) {
> >     //      [....]
> >     } else {
> >             if (likely(cpu == WORK_CPU_UNBOUND))
> >                     add_timer_global(timer);
> >             else
> >                     add_timer_on(timer, cpu);
> >     }
> >
> > The timer is global, so can fire everywhere, and the work item will be
> > enqueued where the timer fired.
> >
> > Since the workqueue work doesn't rely on per-cpu variables, there is no
> > obvious reason that justify the use of a per-cpu workqueue. So change the
> > workqueue with the new system_dfl_long_wq, so that the used workqueue is
> > now unbound and can benefit from scheduler task placement.
> >
>
>
> Ok. So if I am understanding this correctly, the current code uses
> system_long_wq which is per-CPU, but is fired using an unbound timer. As
> a result, whichever CPU the timer triggers on will be the one which
> selects the work queue. From there, the work item will be enqueued to
> that work queue and remain on that work queue until resolving with no
> way for scheduler to adjust it?
>
> With the new change, we schedule on the system_dfl_long_wq which *isn't*
> per CPU, so the scheduler is free to move the task around and
> reschedule. As a result we get better overall behavior with more input
> from the scheduler, instead of effective randomness from the timer which
> is then forced so that such long running task cannot migrate?
>
> That sounds like a pretty good improvement for the cases where the
> queued work doesn't depend on any per-cpu behavior. Nice!

Yes, that's pretty much it!

> I am not sure I can speak to any of the individual drivers here since I
> wouldn't know whether moving that particular work item would be
> affected.. so feel free to take this review with a grain of salt :)
>
> Reviewed-by: Jacob Keller <jacob.e.keller@xxxxxxxxx>

Sure, thank you!

-- 

Marco Crivellari

SUSE Labs