linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Will Deacon <will@kernel.org>
To: Frederic Weisbecker <frederic@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 11:36:21 +0000	[thread overview]
Message-ID: <aXILtazyRtpb3Yjy@willie-the-truck> (raw)
In-Reply-To: <aXIKDduX5qUXvOUX@localhost.localdomain>

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.

Will


  reply	other threads:[~2026-01-22 11:36 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 [this message]
2026-01-22 14:25             ` Frederic Weisbecker
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=aXILtazyRtpb3Yjy@willie-the-truck \
    --to=will@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=frederic@kernel.org \
    --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 \
    /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