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:

quoted

Le Tue, Jan 20, 2026 at 03:15:14PM +0000, Will Deacon a écrit :

quoted

Hi Frederic,

On Thu, Jan 01, 2026 at 11:13:54PM +0100, Frederic Weisbecker wrote:

quoted

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