Re: [PATCH 2/6] kthread: Keep unbound kthreads off nohz_full CPUs

[Frederic Weisbecker]

Le Tue, Nov 03, 2026 at 10:13:38AM -0500, Waiman Long a écrit :
> On 11/3/26 9:01 AM, Frederic Weisbecker wrote:
> > Le Tue, Nov 03, 2026 at 08:59:36PM +1300, Matthew Ruffell a écrit :
> > > From: Caron Wills <caron.wills@xxxxxxxxxx>
> > > 
> > > Since commit 041ee6f3727a ("kthread: Rely on HK_TYPE_DOMAIN for
> > > preferred affinity management") kthread_fetch_affinity() only removes
> > > domain isolated CPUs from a kthread's affinity, assuming that nohz_full
> > > CPUs are always domain isolated as well. Up to v6.13 every kthread
> > > inherited kthreadd's affinity to housekeeping_cpumask(HK_TYPE_KTHREAD),
> > > and from v6.14 the preferred affinity was filtered with HK_TYPE_KTHREAD,
> > > so nohz_full CPUs were always excluded.
> > This was done on purpose because on all setup we have met so far, it didn't
> > make sense to run nohz_full with load balancing. After all the point is to
> > run a pinned single task on a single CPU. We have seen too many misconfigured
> > CPU isolation workloads due to that constraint not being enforced since the
> > origins.
> > 
> > I'm open to counter-arguments of course but you better have a good case.
> 
> I do see configurations where nohz_full/managed_irq CPUs are set at boot
> time without isolcpus=domain. But these nohz_full CPUs are there as a backup
> in case some latency critical workloads need a set of fully isolated CPUs to
> run on.

Sure.

> Right now, isolcpus=domain can be set dynamically by using the
> cpuset isolated partition feature and they will be used when the need
> arises.

Exactly. Whathever way you use to do domain isolation.

-- 
Frederic Weisbecker
SUSE Labs