Re: [RFC PATCH 0/2] Add queue_*() functions and prefer per-cpu workqueue and flag

[Marco Crivellari]

On Thu, May 7, 2026 at 11:27 PM Tejun Heo <tj@xxxxxxxxxx> wrote:
> [...]
> > Anyhow, this idea is based on customer reports I've seen previously.
> > We noticed that with certain workloads, specific per-cpu work creates
> > noise on isolated CPUs. With a flag like that we can identify which
> > workqueues prefer to be per-cpu and *not* for correctness. This allows
> > using a boot parameter / sysctl, for example, to keep those workqueues
> > affined only to housekeeping CPUs.
> >
> > Of course, if we can achieve the same with a system workqueue (like
> > system_prefer_percpu_wq), that would also be fine. I think it would be
> > way easier, it should be similar to what we're doing with
> > system_power_efficient_wq [1].
>
> WQ_AFFN_CPU is more flexible as the tasks aren't pinned to the CPU but there
> may be downsides:
>
> - Concurrency management isn't available.
>
> - Would create more kworkers.
>
> Maybe the original plan can be adapted to:
>
> - Add WQ_PERFER_PERCPU as discussed before.
>
> - At boot time, allow selecting whether to back them with percpu wqs or
>   WQ_AFFN_X unbound ones. Maybe we can even experiment with default to
>   WQ_AFFN_CPU.

Hello Tejun,

You mentioned here "at boot time". What about making this also dynamic,
"moving" the WQs with WQ_PREFER_PERCPU away from CPU N when N is
isolated through a cgroup isolated partition?

I considered checking the flag inside __queue_work(), checking the
isolated CPU mask to see if the CPU is unbound, and then choosing a
different CPU accordingly.

I'm also wondering: when an isolated CPU is added / removed, should we
also act on the work items waiting in the worker pool?
Should the worker pool be DISASSOCIATED when/if only work items queued
with WQ_PREFER_PERCPU are on a CPU being isolated? I thought about
this, and because the worker pool has a list of items queued by
per-CPU WQs, I don't think it should be disassociated. Maybe I'm
missing something btw.

Thanks in advance!

--

Marco Crivellari

SUSE Labs