From: Dave Chinner <dgc@kernel.org>
To: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Marco Crivellari <marco.crivellari@suse.com>,
linux-kernel@vger.kernel.org, linux-xfs@vger.kernel.org,
Tejun Heo <tj@kernel.org>, Lai Jiangshan <jiangshanlai@gmail.com>,
Frederic Weisbecker <frederic@kernel.org>,
Michal Hocko <mhocko@suse.com>,
Anthony Iliopoulos <ailiopoulos@suse.com>,
Carlos Maiolino <cem@kernel.org>
Subject: Re: [PATCH] xfs: convert alloc_workqueue users to WQ_UNBOUND
Date: Fri, 20 Feb 2026 10:05:09 +1100 [thread overview]
Message-ID: <aZeXJeV_EfmOzCxh@dread> (raw)
In-Reply-To: <20260219072556.Bpnr4F5x@linutronix.de>
On Thu, Feb 19, 2026 at 08:25:56AM +0100, Sebastian Andrzej Siewior wrote:
> On 2026-02-19 12:24:38 [+1100], Dave Chinner wrote:
> > > The changes from per-cpu to unbound will help to improve situations where
> > > CPU isolation is used, because unbound work can be moved away from
> > > isolated CPUs.
> >
> > If you are running operations through the XFS filesystem on isolated
> > CPUs, then you absolutely need some of these the per-cpu workqueues
> > running on those isolated CPUs too.
> >
> > Also, these workqueues are typically implemented these ways to meet
> > performancei targets, concurrency constraints or algorithm
> > requirements. Changes like this need a bunch of XFS metadata
> > scalability benchmarks on high end server systems under a variety of
> > conditions to at least show there aren't any obvious any behavioural
> > or performance regressions that result from the change.
>
> So all of those (below) where you say "performance critical", those
> work items are only enqueued from an interrupt?
No.
> Never origin from a user task?
Inode GC is most definitely driven from user tasks with unbound
concurrency (e.g. unlink(), close() and other syscalls that can drop
a file reference). It can also be driven by the kernel through
direct reclaim (again, from user task context with unbound
concurrency), and from pure kernel context via reclaim from kswapd
(strictly bound concurrency in this case).
The lockless per-cpu queuing and processing algorithm was added
because the inode eviction path from user context is performance
critical. The original version using unbound workqueues had major
performance regressions. There's discussion of the reasons for
those performance regressions and numbers around those in the
original discussions and prototypes:
https://lore.kernel.org/linux-xfs/20210802103559.GH2757197@dread.disaster.area/
https://lore.kernel.org/linux-xfs/20210804032030.GT3601443@magnolia/
-Dave.
--
Dave Chinner
dgc@kernel.org
next prev parent reply other threads:[~2026-02-19 23:05 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-18 16:56 [PATCH] xfs: convert alloc_workqueue users to WQ_UNBOUND Marco Crivellari
2026-02-19 1:24 ` Dave Chinner
2026-02-19 7:25 ` Sebastian Andrzej Siewior
2026-02-19 23:05 ` Dave Chinner [this message]
2026-02-20 7:19 ` Sebastian Andrzej Siewior
2026-02-19 9:20 ` Michal Hocko
2026-02-19 22:22 ` Dave Chinner
2026-02-20 9:29 ` Michal Hocko
2026-02-19 9:35 ` Marco Crivellari
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aZeXJeV_EfmOzCxh@dread \
--to=dgc@kernel.org \
--cc=ailiopoulos@suse.com \
--cc=bigeasy@linutronix.de \
--cc=cem@kernel.org \
--cc=frederic@kernel.org \
--cc=jiangshanlai@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=marco.crivellari@suse.com \
--cc=mhocko@suse.com \
--cc=tj@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox