From: Waiman Long <llong@redhat.com>
To: Frederic Weisbecker <frederic@kernel.org>,
LKML <linux-kernel@vger.kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
Marco Crivellari <marco.crivellari@suse.com>,
Michal Hocko <mhocko@suse.com>,
Peter Zijlstra <peterz@infradead.org>, Tejun Heo <tj@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Will Deacon <will@kernel.org>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 27/33] sched/arm64: Move fallback task cpumask to HK_TYPE_DOMAIN
Date: Tue, 2 Sep 2025 12:43:16 -0400 [thread overview]
Message-ID: <26d5ced7-8f35-49b2-b342-c6b55dde9c66@redhat.com> (raw)
In-Reply-To: <20250829154814.47015-28-frederic@kernel.org>
On 8/29/25 11:48 AM, 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 is always a subset of the
> housekeeping mask of nohz_full CPUs (there can be CPUs that are domain
> isolated but not nohz_full, OTOH there can'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.
>
> CC: linux-arm-kernel@lists.infradead.org
> Signed-off-by: Frederic Weisbecker <frederic@kernel.org>
> ---
> arch/arm64/kernel/cpufeature.c | 18 ++++++++++++---
> include/linux/cpu.h | 4 ++++
> kernel/cgroup/cpuset.c | 40 +++++++++++++++++++++++-----------
> 3 files changed, 46 insertions(+), 16 deletions(-)
>
> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> index 9ad065f15f1d..38046489d2ea 100644
> --- a/arch/arm64/kernel/cpufeature.c
> +++ b/arch/arm64/kernel/cpufeature.c
> @@ -1653,6 +1653,18 @@ has_cpuid_feature(const struct arm64_cpu_capabilities *entry, int scope)
> return feature_matches(val, entry);
> }
>
> +/*
> + * 32 bits support CPUs can't be isolated because tasks may be
> + * arbitrarily affine to them, defeating the purpose of isolation.
> + */
> +bool arch_isolated_cpus_can_update(struct cpumask *new_cpus)
> +{
> + if (static_branch_unlikely(&arm64_mismatched_32bit_el0))
> + return !cpumask_intersects(cpu_32bit_el0_mask, new_cpus);
> + else
> + return true;
> +}
> +
> const struct cpumask *system_32bit_el0_cpumask(void)
> {
> if (!system_supports_32bit_el0())
> @@ -1666,7 +1678,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)
> @@ -3963,8 +3975,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;
> }
> diff --git a/include/linux/cpu.h b/include/linux/cpu.h
> index b91b993f58ee..8bb239080534 100644
> --- a/include/linux/cpu.h
> +++ b/include/linux/cpu.h
> @@ -228,4 +228,8 @@ static inline bool cpu_attack_vector_mitigated(enum cpu_attack_vectors v)
> #define smt_mitigations SMT_MITIGATIONS_OFF
> #endif
>
> +struct cpumask;
> +
> +bool arch_isolated_cpus_can_update(struct cpumask *new_cpus);
> +
> #endif /* _LINUX_CPU_H_ */
> diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c
> index 8260dd699fd8..cf99ea844c1d 100644
> --- a/kernel/cgroup/cpuset.c
> +++ b/kernel/cgroup/cpuset.c
> @@ -1352,33 +1352,47 @@ static bool partition_xcpus_del(int old_prs, struct cpuset *parent,
> return isolcpus_updated;
> }
>
> +bool __weak arch_isolated_cpus_can_update(struct cpumask *new_cpus)
> +{
> + return true;
> +}
> +
> /*
> - * isolcpus_nohz_conflict - check for isolated & nohz_full conflicts
> + * isolated_cpus_can_update - check for conflicts against housekeeping and
> + * CPUs capabilities.
> * @new_cpus: cpu mask for cpus that are going to be isolated
> - * Return: true if there is conflict, false otherwise
> + * Return: true if there no conflict, false otherwise
> *
> - * If nohz_full is enabled and we have isolated CPUs, their combination must
> - * still leave housekeeping CPUs.
> + * Check for conflicts:
> + * - If nohz_full is enabled and there are isolated CPUs, their combination must
> + * still leave housekeeping CPUs.
> + * - Architecture has CPU capabilities incompatible with being isolated
> */
> -static bool isolcpus_nohz_conflict(struct cpumask *new_cpus)
> +static bool isolated_cpus_can_update(struct cpumask *new_cpus)
> {
> cpumask_var_t full_hk_cpus;
> - int res = false;
> + bool res;
> +
> + if (!arch_isolated_cpus_can_update(new_cpus))
> + return false;
>
> if (!housekeeping_enabled(HK_TYPE_KERNEL_NOISE))
> - return false;
> + return true;
>
> if (!alloc_cpumask_var(&full_hk_cpus, GFP_KERNEL))
> - return true;
> + return false;
> +
> + res = true;
>
> cpumask_and(full_hk_cpus, housekeeping_cpumask(HK_TYPE_KERNEL_NOISE),
> housekeeping_cpumask(HK_TYPE_DOMAIN));
> cpumask_andnot(full_hk_cpus, full_hk_cpus, isolated_cpus);
> cpumask_and(full_hk_cpus, full_hk_cpus, cpu_online_mask);
We should construct the new cpumask by adding new CPUs and removing old
ones from the existing isolated_cpus and pass it to
arch_isolated_cpus_can_update() for the checking to be correct.
Cheers,
Longman
prev parent reply other threads:[~2025-09-02 22:57 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20250829154814.47015-1-frederic@kernel.org>
2025-08-29 15:48 ` [PATCH 25/33] sched: Switch the fallback task allowed cpumask to HK_TYPE_DOMAIN Frederic Weisbecker
2025-08-29 15:48 ` [PATCH 27/33] sched/arm64: Move fallback task " Frederic Weisbecker
2025-09-02 16:43 ` Waiman Long [this message]
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=26d5ced7-8f35-49b2-b342-c6b55dde9c66@redhat.com \
--to=llong@redhat.com \
--cc=catalin.marinas@arm.com \
--cc=frederic@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marco.crivellari@suse.com \
--cc=mhocko@suse.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=tj@kernel.org \
--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;
as well as URLs for NNTP newsgroup(s).