Message-ID: <aXIzbmitdoJIMFCP@localhost.localdomain>
Date: Thu, 22 Jan 2026 15:25:50 +0100
From: Frederic Weisbecker <frederic@...nel.org>
To: Will Deacon <will@...nel.org>
Cc: LKML <linux-kernel@...r.kernel.org>,
	Michal Koutný <mkoutny@...e.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Bjorn Helgaas <bhelgaas@...gle.com>,
	Catalin Marinas <catalin.marinas@....com>,
	Chen Ridong <chenridong@...wei.com>,
	Danilo Krummrich <dakr@...nel.org>,
	"David S . Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Gabriele Monaco <gmonaco@...hat.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Ingo Molnar <mingo@...hat.com>, Jakub Kicinski <kuba@...nel.org>,
	Jens Axboe <axboe@...nel.dk>, Johannes Weiner <hannes@...xchg.org>,
	Lai Jiangshan <jiangshanlai@...il.com>,
	Marco Crivellari <marco.crivellari@...e.com>,
	Michal Hocko <mhocko@...e.com>, Muchun Song <muchun.song@...ux.dev>,
	Paolo Abeni <pabeni@...hat.com>,
	Peter Zijlstra <peterz@...radead.org>, Phil Auld <pauld@...hat.com>,
	"Rafael J . Wysocki" <rafael@...nel.org>,
	Roman Gushchin <roman.gushchin@...ux.dev>,
	Shakeel Butt <shakeel.butt@...ux.dev>,
	Simon Horman <horms@...nel.org>, Tejun Heo <tj@...nel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Vlastimil Babka <vbabka@...e.cz>, Waiman Long <longman@...hat.com>,
	cgroups@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	linux-block@...r.kernel.org, linux-mm@...ck.org,
	linux-pci@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH 29/33] sched/arm64: Move fallback task cpumask to
 HK_TYPE_DOMAIN

Le Thu, Jan 22, 2026 at 11:36:21AM +0000, Will Deacon a écrit :
> On Thu, Jan 22, 2026 at 12:29:17PM +0100, Frederic Weisbecker wrote:
> > 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@...nel.org>
> > > > > > Reviewed-by: Waiman Long <longman@...hat.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.
> 
> Honestly, I'm not sure I'd bother trying to be smart here. Even if the
> system has enabled support for mismatched 32-bit CPUs, things should
> still work properly with nohz_full/isolcpus if all the tasks are 64-bit,
> right?
> 
> In which case, I'd just document whatever weird behaviour you get if
> somebody throws 32-bit tasks into the mix. Adding hooks to the generic
> code for this use-case just seems like a waste, as they're not going to
> be used in practice and it increases the maintenance burden.

Ok, how does this updated version look now?

---
From: Frederic Weisbecker <frederic@...nel.org>
Date: Thu, 24 Jul 2025 23:38:48 +0200
Subject: [PATCH] sched/arm64: Move fallback task cpumask to HK_TYPE_DOMAIN

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 subset 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. Note that cpuset isolated partitions are not supported on those
systems and may result in undefined behaviour.

Signed-off-by: Frederic Weisbecker <frederic@...nel.org>
Cc: Catalin Marinas <catalin.marinas@....com>
Cc: Marco Crivellari <marco.crivellari@...e.com>
Cc: Michal Hocko <mhocko@...e.com>
Cc: Peter Zijlstra <peterz@...radead.org>
Cc: Tejun Heo <tj@...nel.org>
Cc: Thomas Gleixner <tglx@...utronix.de>
Cc: Waiman Long <longman@...hat.com>
Cc: Will Deacon <will@...nel.org>
Cc: Catalin Marinas <catalin.marinas@....com>
Cc: linux-arm-kernel@...ts.infradead.org
---
 Documentation/arch/arm64/asymmetric-32bit.rst | 12 ++++++++----
 arch/arm64/kernel/cpufeature.c                |  6 +++---
 2 files changed, 11 insertions(+), 7 deletions(-)

diff --git a/Documentation/arch/arm64/asymmetric-32bit.rst b/Documentation/arch/arm64/asymmetric-32bit.rst
index 57b8d7476f71..fc0c350c5e00 100644
--- a/Documentation/arch/arm64/asymmetric-32bit.rst
+++ b/Documentation/arch/arm64/asymmetric-32bit.rst
@@ -154,10 +154,14 @@ mode will return to host userspace with an ``exit_reason`` of
 ``KVM_EXIT_FAIL_ENTRY`` and will remain non-runnable until successfully
 re-initialised by a subsequent ``KVM_ARM_VCPU_INIT`` operation.
 
-NOHZ FULL
----------
+SCHEDULER DOMAIN ISOLATION
+--------------------------
 
-To avoid perturbing an adaptive-ticks CPU (specified using
-``nohz_full=``) when a 32-bit task is forcefully migrated, these CPUs
+To avoid perturbing a boot-defined domain isolated CPU (specified using
+``isolcpus=[domain]``) when a 32-bit task is forcefully migrated, these CPUs
 are treated as 64-bit-only when support for asymmetric 32-bit systems
 is enabled.
+
+However as opposed to boot-defined domain isolation, runtime-defined domain
+isolation using cpuset isolated partition is not advised on asymmetric
+32-bit systems and will result in undefined behaviour.
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index c840a93b9ef9..f0e66cb27d17 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -1669,7 +1669,7 @@ const struct cpumask *system_32bit_el0_cpumask(void)
 
 const struct cpumask *task_cpu_fallback_mask(struct task_struct *p)
 {
-	return __task_cpu_possible_mask(p, housekeeping_cpumask(HK_TYPE_TICK));
+	return __task_cpu_possible_mask(p, housekeeping_cpumask(HK_TYPE_DOMAIN));
 }
 
 static int __init parse_32bit_el0_param(char *str)
@@ -3987,8 +3987,8 @@ static int enable_mismatched_32bit_el0(unsigned int cpu)
 	bool cpu_32bit = false;
 
 	if (id_aa64pfr0_32bit_el0(info->reg_id_aa64pfr0)) {
-		if (!housekeeping_cpu(cpu, HK_TYPE_TICK))
-			pr_info("Treating adaptive-ticks CPU %u as 64-bit only\n", cpu);
+		if (!housekeeping_cpu(cpu, HK_TYPE_DOMAIN))
+			pr_info("Treating domain isolated CPU %u as 64-bit only\n", cpu);
 		else
 			cpu_32bit = true;
 	}
-- 
2.51.1

Powered by blists - more mailing lists