Re: [PATCH] xfs: convert alloc_workqueue users to WQ_UNBOUND

[Michal Hocko]

On Fri 20-02-26 09:22:19, Dave Chinner wrote:
> On Thu, Feb 19, 2026 at 10:20:54AM +0100, Michal Hocko wrote:
[...]
> > The usecase is that isolated workload needs to perform fs operations at
> > certain stages of the operation. Then it moves over to "do not disturb"
> > mode when it operates in the userspace and shouldn't be disrupted by the
> > kernel. We do observe that those workers trigger at later time and
> > disturb the workload when not appropriate.
> 
> Define "later time".

After workload transitions to the "do not disturb" operation. 

> Also, please explain how the XFS work gets queued to run on these
> isolated CPUs?  If there's nothing fs, storage or memory reclaim
> related running on the isolated CPU, then none of the XFS workqueues
> should ever trigger on those CPUs. 

I do not have full visibility in the workload (i.e. access to the code)
so we only rely on tracing data. We know that the workload operates on
the set of isolated cpus and each component is consuming a dedicated
CPU. We also do see (among others) XFS workers interfering. I am not
able to link exact syscalls to those worker items but we pressume those
are result of prior workload execution as not much else is running on
those CPUs.

> IOWs, if you are getting unexpected work triggers on isolated CPUs,
> then you need to first explain how those unexpected triggers are
> occurring. Once you can explain how the per-cpu workqueues are
> responsible for the unexpected behaviour rather than just being the
> visible symptom of something else going wrong (e.g. a scheduler or
> workqueue bug), then we can discussion changing the XFS code....

Understood.

Thanks!
-- 
Michal Hocko
SUSE Labs