From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
To: Chuyi Zhou <zhouchuyi@bytedance.com>
Cc: tglx@kernel.org, mingo@redhat.com, luto@kernel.org,
peterz@infradead.org, paulmck@kernel.org, muchun.song@linux.dev,
bp@alien8.de, dave.hansen@linux.intel.com, pbonzini@redhat.com,
clrkwllms@kernel.org, rostedt@goodmis.org, nadav.amit@gmail.com,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v6 04/12] smp: Use task-local IPI cpumask in smp_call_function_many_cond()
Date: Wed, 3 Jun 2026 12:54:48 +0200 [thread overview]
Message-ID: <20260603105448.2bwLH_XI@linutronix.de> (raw)
In-Reply-To: <20260528151338.617843-5-zhouchuyi@bytedance.com>
On 2026-05-28 23:13:30 [+0800], Chuyi Zhou wrote:
> --- a/include/linux/smp.h
> +++ b/include/linux/smp.h
> @@ -167,6 +167,11 @@ void smp_call_function_many(const struct cpumask *mask,
> int smp_call_function_any(const struct cpumask *mask,
> smp_call_func_t func, void *info, int wait);
>
> +#ifdef CONFIG_PREEMPTION
> +int smp_task_ipi_mask_alloc(struct task_struct *task);
> +void smp_task_ipi_mask_free(struct task_struct *task);
> +#endif
> +
> void kick_all_cpus_sync(void);
> void wake_up_all_idle_cpus(void);
> bool cpus_peek_for_pending_ipi(const struct cpumask *mask);
> @@ -310,4 +315,14 @@ bool csd_lock_is_stuck(void);
> static inline bool csd_lock_is_stuck(void) { return false; }
> #endif
>
> +#if !defined(CONFIG_SMP) || !defined(CONFIG_PREEMPTION)
> +static inline int smp_task_ipi_mask_alloc(struct task_struct *task)
> +{
> + return 0;
> +}
> +static inline void smp_task_ipi_mask_free(struct task_struct *task)
> +{
> +}
> +#endif
> +
It might make sense to move them closer together after
CONFIG_UP_LATE_INIT so you have
#if defined(CONFIG_PREEMPTION) && defined(CONFIG_SMP)
int smp_task_ipi_mask_alloc(struct task_struct *task);
void smp_task_ipi_mask_free(struct task_struct *task);
#else
static inline int smp_task_ipi_mask_alloc(struct task_struct *task)
{
return 0;
}
static inline void smp_task_ipi_mask_free(struct task_struct *task) { }
#endif
…
> --- a/kernel/smp.c
> +++ b/kernel/smp.c
> @@ -1010,6 +1061,9 @@ EXPORT_SYMBOL(nr_cpu_ids);
> void __init setup_nr_cpu_ids(void)
> {
> set_nr_cpu_ids(find_last_bit(cpumask_bits(cpu_possible_mask), NR_CPUS) + 1);
> +
> + if (IS_ENABLED(CONFIG_PREEMPTION) && cpumask_size() <= sizeof(unsigned long))
> + static_branch_enable(&ipi_mask_inlined);
Nitpicks:
We restrict the inline case to a large enough size.
smp_call_function_many_cond() can deal with with a NULL pointer and will
use the per-CPU mask in this cases and not enable PREEMPTION early.
This happens for instance on !PREEMPT kernels and request issued by the
init task which is defined at compile at init/init_task.c. Not sure if
this is a problem as it did not trigger is testing.
Just to let you know.
The inline condition is based on cpumask_size() which uses
large_cpumask_bits. This is used by cpumask_copy() and cpumask_clear()
because the underlying operation can be optimized if the size is a
constant.
large_cpumask_bits remains a constant as long as CONFIG_NR_CPUS is <=
256 on 64bit mirroring CONFIG_NR_CPUS. That means if you boot this on a
4 core CPU then it will not inline the operation if CONFIG_NR_CPUS is
say 128 to cope with larger machines. Debian for instance uses here
NR_CPUS=8192 so it will inline it.
All the cpumask operation that are used by smp_call_function_many_cond()
for this task_mask are based on small_cpumask_bits. It could be used to
allow the inline case if CONFIG_NR_CPUS=256 but boot with 8 CPUs. It
would risk breakage if the code changes one does
cpumask_clear(task_mask).
Just two things that I noticed while looking at it.
Reviewed-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> }
>
> /* Called by boot processor to activate the rest. */
Sebastian
next prev parent reply other threads:[~2026-06-03 10:54 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-28 15:13 [PATCH v6 00/12] Allow preemption during IPI completion waiting to improve real-time performance Chuyi Zhou
2026-05-28 15:13 ` [PATCH v6 01/12] smp: Disable preemption explicitly in __csd_lock_wait Chuyi Zhou
2026-05-28 15:13 ` [PATCH v6 02/12] smp: Enable preemption early in smp_call_function_single Chuyi Zhou
2026-05-28 15:13 ` [PATCH v6 03/12] smp: Refactor remote CPU selection in smp_call_function_any() Chuyi Zhou
2026-05-28 15:13 ` [PATCH v6 04/12] smp: Use task-local IPI cpumask in smp_call_function_many_cond() Chuyi Zhou
2026-06-03 10:54 ` Sebastian Andrzej Siewior [this message]
2026-06-03 11:48 ` Chuyi Zhou
2026-06-03 12:21 ` Sebastian Andrzej Siewior
2026-05-28 15:13 ` [PATCH v6 05/12] smp: Alloc percpu csd data in smpcfd_prepare_cpu() only once Chuyi Zhou
2026-05-28 15:13 ` [PATCH v6 06/12] smp: Enable preemption early in smp_call_function_many_cond Chuyi Zhou
2026-06-03 11:00 ` Sebastian Andrzej Siewior
2026-06-03 11:54 ` Chuyi Zhou
2026-05-28 15:13 ` [PATCH v6 07/12] smp: Remove preempt_disable from smp_call_function Chuyi Zhou
2026-05-28 15:13 ` [PATCH v6 08/12] smp: Remove preempt_disable from on_each_cpu_cond_mask Chuyi Zhou
2026-05-28 15:13 ` [PATCH v6 09/12] scftorture: Remove preempt_disable in scftorture_invoke_one Chuyi Zhou
2026-05-28 15:13 ` [PATCH v6 10/12] x86/mm: Move flush_tlb_info back to the stack Chuyi Zhou
2026-06-04 20:54 ` Dave Hansen
2026-06-04 21:11 ` Nadav Amit
2026-06-04 21:16 ` Dave Hansen
2026-06-04 21:21 ` Nadav Amit
2026-06-05 2:54 ` Chuyi Zhou
2026-05-28 15:13 ` [PATCH v6 11/12] x86/mm: Enable preemption during native_flush_tlb_multi Chuyi Zhou
2026-06-04 21:15 ` Dave Hansen
2026-06-05 3:36 ` Chuyi Zhou
2026-05-28 15:13 ` [PATCH v6 12/12] x86/mm: Enable preemption during flush_tlb_kernel_range Chuyi Zhou
2026-06-04 21:21 ` Dave Hansen
2026-06-05 3:51 ` Chuyi Zhou
2026-05-28 19:47 ` [PATCH v6 00/12] Allow preemption during IPI completion waiting to improve real-time performance Paul E. McKenney
2026-05-29 3:22 ` Chuyi Zhou
2026-05-29 6:41 ` Sebastian Andrzej Siewior
2026-06-03 11:02 ` Sebastian Andrzej Siewior
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=20260603105448.2bwLH_XI@linutronix.de \
--to=bigeasy@linutronix.de \
--cc=bp@alien8.de \
--cc=clrkwllms@kernel.org \
--cc=dave.hansen@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=muchun.song@linux.dev \
--cc=nadav.amit@gmail.com \
--cc=paulmck@kernel.org \
--cc=pbonzini@redhat.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=tglx@kernel.org \
--cc=zhouchuyi@bytedance.com \
/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