From: Frederic Weisbecker <frederic@kernel.org>
To: Will Deacon <will@kernel.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
"Michal Koutný" <mkoutny@suse.com>,
"Andrew Morton" <akpm@linux-foundation.org>,
"Bjorn Helgaas" <bhelgaas@google.com>,
"Catalin Marinas" <catalin.marinas@arm.com>,
"Chen Ridong" <chenridong@huawei.com>,
"Danilo Krummrich" <dakr@kernel.org>,
"David S . Miller" <davem@davemloft.net>,
"Eric Dumazet" <edumazet@google.com>,
"Gabriele Monaco" <gmonaco@redhat.com>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Ingo Molnar" <mingo@redhat.com>,
"Jakub Kicinski" <kuba@kernel.org>,
"Jens Axboe" <axboe@kernel.dk>,
"Johannes Weiner" <hannes@cmpxchg.org>,
"Lai Jiangshan" <jiangshanlai@gmail.com>,
"Marco Crivellari" <marco.crivellari@suse.com>,
"Michal Hocko" <mhocko@suse.com>,
"Muchun Song" <muchun.song@linux.dev>,
"Paolo Abeni" <pabeni@redhat.com>,
"Peter Zijlstra" <peterz@infradead.org>,
"Phil Auld" <pauld@redhat.com>,
"Rafael J . Wysocki" <rafael@kernel.org>,
"Roman Gushchin" <roman.gushchin@linux.dev>,
"Shakeel Butt" <shakeel.butt@linux.dev>,
"Simon Horman" <horms@kernel.org>, "Tejun Heo" <tj@kernel.org>,
"Thomas Gleixner" <tglx@linutronix.de>,
"Vlastimil Babka" <vbabka@suse.cz>,
"Waiman Long" <longman@redhat.com>,
cgroups@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-block@vger.kernel.org, linux-mm@kvack.org,
linux-pci@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: [PATCH 29/33] sched/arm64: Move fallback task cpumask to HK_TYPE_DOMAIN
Date: Thu, 22 Jan 2026 15:25:50 +0100 [thread overview]
Message-ID: <aXIzbmitdoJIMFCP@localhost.localdomain> (raw)
In-Reply-To: <aXILtazyRtpb3Yjy@willie-the-truck>
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@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.
>
> 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@kernel.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@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Marco Crivellari <marco.crivellari@suse.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Tejun Heo <tj@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Waiman Long <longman@redhat.com>
Cc: Will Deacon <will@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: linux-arm-kernel@lists.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
next prev parent reply other threads:[~2026-01-22 14:25 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-01 22:13 [PATCH 00/33 v6] cpuset/isolation: Honour kthreads preferred affinity Frederic Weisbecker
2026-01-01 22:13 ` [PATCH 01/33] PCI: Prepare to protect against concurrent isolated cpuset change Frederic Weisbecker
2026-01-07 19:05 ` Bjorn Helgaas
2026-01-07 23:30 ` Frederic Weisbecker
2026-01-07 23:39 ` Bjorn Helgaas
2026-01-08 8:43 ` Jinhui Guo
2026-01-22 16:14 ` Bjorn Helgaas
2026-01-01 22:13 ` [PATCH 02/33] cpu: Revert "cpu/hotplug: Prevent self deadlock on CPU hot-unplug" Frederic Weisbecker
2026-01-01 22:13 ` [PATCH 03/33] memcg: Prepare to protect against concurrent isolated cpuset change Frederic Weisbecker
2026-01-01 22:13 ` [PATCH 04/33] mm: vmstat: " Frederic Weisbecker
2026-01-01 22:13 ` [PATCH 05/33] sched/isolation: Save boot defined domain flags Frederic Weisbecker
2026-01-12 18:03 ` Waiman Long
2026-01-01 22:13 ` [PATCH 06/33] cpuset: Convert boot_hk_cpus to use HK_TYPE_DOMAIN_BOOT Frederic Weisbecker
2026-01-01 22:13 ` [PATCH 07/33] driver core: cpu: Convert /sys/devices/system/cpu/isolated " Frederic Weisbecker
2026-01-01 22:13 ` [PATCH 08/33] net: Keep ignoring isolated cpuset change Frederic Weisbecker
2026-01-01 22:13 ` [PATCH 09/33] block: Protect against concurrent " Frederic Weisbecker
2026-01-01 22:13 ` [PATCH 10/33] timers/migration: Prevent from lockdep false positive warning Frederic Weisbecker
2026-01-01 22:13 ` [PATCH 11/33] cpu: Provide lockdep check for CPU hotplug lock write-held Frederic Weisbecker
2026-01-01 22:13 ` [PATCH 12/33] cpuset: Provide lockdep check for cpuset lock held Frederic Weisbecker
2026-01-12 1:43 ` Waiman Long
2026-01-12 17:53 ` Waiman Long
2026-01-01 22:13 ` [PATCH 13/33] sched/isolation: Convert housekeeping cpumasks to rcu pointers Frederic Weisbecker
2026-01-07 11:56 ` Simon Horman
2026-01-12 2:45 ` Waiman Long
2026-01-12 21:34 ` Frederic Weisbecker
2026-01-01 22:13 ` [PATCH 14/33] cpuset: Update HK_TYPE_DOMAIN cpumask from cpuset Frederic Weisbecker
2026-01-22 11:24 ` Chen Ridong
2026-01-01 22:13 ` [PATCH 15/33] sched/isolation: Flush memcg workqueues on cpuset isolated partition change Frederic Weisbecker
2026-01-01 22:13 ` [PATCH 16/33] sched/isolation: Flush vmstat " Frederic Weisbecker
2026-01-01 22:13 ` [PATCH 17/33] PCI: Flush PCI probe workqueue " Frederic Weisbecker
2026-01-22 16:14 ` Bjorn Helgaas
2026-01-01 22:13 ` [PATCH 18/33] cpuset: Propagate cpuset isolation update to workqueue through housekeeping Frederic Weisbecker
2026-01-01 22:13 ` [PATCH 19/33] cpuset: Propagate cpuset isolation update to timers " Frederic Weisbecker
2026-01-01 22:13 ` [PATCH 20/33] timers/migration: Remove superfluous cpuset isolation test Frederic Weisbecker
2026-01-01 22:13 ` [PATCH 21/33] cpuset: Remove cpuset_cpu_is_isolated() Frederic Weisbecker
2026-01-01 22:13 ` [PATCH 22/33] sched/isolation: Remove HK_TYPE_TICK test from cpu_is_isolated() Frederic Weisbecker
2026-01-01 22:13 ` [PATCH 23/33] PCI: Remove superfluous HK_TYPE_WQ check Frederic Weisbecker
2026-01-22 16:15 ` Bjorn Helgaas
2026-01-01 22:13 ` [PATCH 24/33] kthread: Refine naming of affinity related fields Frederic Weisbecker
2026-01-01 22:13 ` [PATCH 25/33] kthread: Include unbound kthreads in the managed affinity list Frederic Weisbecker
2026-01-01 22:13 ` [PATCH 26/33] kthread: Include kthreadd to " Frederic Weisbecker
2026-01-01 22:13 ` [PATCH 27/33] kthread: Rely on HK_TYPE_DOMAIN for preferred affinity management Frederic Weisbecker
2026-01-01 22:13 ` [PATCH 28/33] sched: Switch the fallback task allowed cpumask to HK_TYPE_DOMAIN Frederic Weisbecker
2026-01-01 22:13 ` [PATCH 29/33] sched/arm64: Move fallback task " Frederic Weisbecker
2026-01-20 15:15 ` Will Deacon
2026-01-21 17:06 ` Frederic Weisbecker
2026-01-22 9:56 ` Will Deacon
2026-01-22 11:29 ` Frederic Weisbecker
2026-01-22 11:36 ` Will Deacon
2026-01-22 14:25 ` Frederic Weisbecker [this message]
2026-01-01 22:13 ` [PATCH 30/33] kthread: Honour kthreads preferred affinity after cpuset changes Frederic Weisbecker
2026-01-01 22:13 ` [PATCH 31/33] kthread: Comment on the purpose and placement of kthread_affine_node() call Frederic Weisbecker
2026-01-01 22:13 ` [PATCH 32/33] kthread: Document kthread_affine_preferred() Frederic Weisbecker
2026-01-01 22:13 ` [PATCH 33/33] doc: Add housekeeping documentation Frederic Weisbecker
2026-01-12 18:23 ` [PATCH 00/33 v6] cpuset/isolation: Honour kthreads preferred affinity Waiman Long
2026-01-12 22:09 ` Frederic Weisbecker
2026-01-13 1:49 ` Waiman Long
-- strict thread matches above, loose matches on Subject: below --
2026-01-25 22:45 [PATCH 00/33 v7] " Frederic Weisbecker
2026-01-25 22:45 ` [PATCH 29/33] sched/arm64: Move fallback task cpumask to HK_TYPE_DOMAIN Frederic Weisbecker
2026-01-26 13:52 ` Will Deacon
2025-12-24 13:44 [PATCH 00/33 v5] cpuset/isolation: Honour kthreads preferred affinity Frederic Weisbecker
2025-12-24 13:45 ` [PATCH 29/33] sched/arm64: Move fallback task cpumask to HK_TYPE_DOMAIN Frederic Weisbecker
2025-12-26 23:46 ` Waiman Long
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=aXIzbmitdoJIMFCP@localhost.localdomain \
--to=frederic@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=axboe@kernel.dk \
--cc=bhelgaas@google.com \
--cc=catalin.marinas@arm.com \
--cc=cgroups@vger.kernel.org \
--cc=chenridong@huawei.com \
--cc=dakr@kernel.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=gmonaco@redhat.com \
--cc=gregkh@linuxfoundation.org \
--cc=hannes@cmpxchg.org \
--cc=horms@kernel.org \
--cc=jiangshanlai@gmail.com \
--cc=kuba@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-pci@vger.kernel.org \
--cc=longman@redhat.com \
--cc=marco.crivellari@suse.com \
--cc=mhocko@suse.com \
--cc=mingo@redhat.com \
--cc=mkoutny@suse.com \
--cc=muchun.song@linux.dev \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=pauld@redhat.com \
--cc=peterz@infradead.org \
--cc=rafael@kernel.org \
--cc=roman.gushchin@linux.dev \
--cc=shakeel.butt@linux.dev \
--cc=tglx@linutronix.de \
--cc=tj@kernel.org \
--cc=vbabka@suse.cz \
--cc=will@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