Re: [PATCH 29/33] sched/arm64: Move fallback task cpumask to HK_TYPE_DOMAIN

[Frederic Weisbecker <frederic@kernel.org>]

Le Thu, Jan 22, 2026 at 09:56:29AM +0000, Will Deacon a écrit :
> On Wed, Jan 21, 2026 at 06:06:07PM +0100, Frederic Weisbecker wrote:
> > Le Tue, Jan 20, 2026 at 03:15:14PM +0000, Will Deacon a écrit :
> > > Hi Frederic,
> > > 
> > > On Thu, Jan 01, 2026 at 11:13:54PM +0100, Frederic Weisbecker wrote:
> > > > When none of the allowed CPUs of a task are online, it gets migrated
> > > > to the fallback cpumask which is all the non nohz_full CPUs.
> > > > 
> > > > However just like nohz_full CPUs, domain isolated CPUs don't want to be
> > > > disturbed by tasks that have lost their CPU affinities.
> > > > 
> > > > And since nohz_full rely on domain isolation to work correctly, the
> > > > housekeeping mask of domain isolated CPUs should always be a superset of
> > > > the housekeeping mask of nohz_full CPUs (there can be CPUs that are
> > > > domain isolated but not nohz_full, OTOH there shouldn't be nohz_full
> > > > CPUs that are not domain isolated):
> > > > 
> > > > 	HK_TYPE_DOMAIN | HK_TYPE_KERNEL_NOISE == HK_TYPE_DOMAIN
> > > > 
> > > > Therefore use HK_TYPE_DOMAIN as the appropriate fallback target for
> > > > tasks and since this cpumask can be modified at runtime, make sure
> > > > that 32 bits support CPUs on ARM64 mismatched systems are not isolated
> > > > by cpusets.
> > > > 
> > > > Signed-off-by: Frederic Weisbecker <frederic@kernel.org>
> > > > Reviewed-by: Waiman Long <longman@redhat.com>
> > > > ---
> > > >  arch/arm64/kernel/cpufeature.c | 18 +++++++++++++++---
> > > >  include/linux/cpu.h            |  4 ++++
> > > >  kernel/cgroup/cpuset.c         | 17 ++++++++++++++---
> > > >  3 files changed, 33 insertions(+), 6 deletions(-)
> > > 
> > > tbh, I'd also be fine just saying that isolation isn't reliable on these
> > > systems and then you don't need to add the extra arch hook.
> > 
> > Hmm, I think I heard about nohz_full usage on arm64 but I'm not sure.
> > And I usually expect isolcpus or cpuset isolated partitions to be even
> > more broadly used, it's lighter isolation with less constraints.
> > 
> > Anyway you're probably right that we could remove isolation support here
> > but I don't want to break any existing user.
> 
> fwiw, I think it's only some Android markets using the mismatched 32-bit
> support and we're definitely not using nohz_full there.

Now that removal becomes appealing. And what about isolcpus= / isolated cpuset
which only consist in scheduler domain isolation? Probably not used by android
either.

Ok but is there a way to detect on early boot that the system has mismatched
32 bits support? Because I need to fail nohz_full= and isolcpus= boot parameters
early on top of this information without waiting for secondary CPUs boot.

Thanks.

-- 
Frederic Weisbecker
SUSE Labs