From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A12B23CB919 for ; Wed, 3 Jun 2026 10:54:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=193.142.43.55 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780484092; cv=none; b=Ev1sOMGVQ1MYyQzeLF3iCRbKR6+bDW4sGFBIkqT6CjknPS/r8nvixqqh+9tRa4KuJnKSzI0ZJDZzK6BgdztkT61Ugg0tklaoiIx+Ocw2IuefwV1uI4C6JPCVsV+O+CaM9IVXEu07QLIVtLfJhF4QadcVwi6qYzouidIG1zTFt9M= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780484092; c=relaxed/simple; bh=gr+ZbTcuKVkJ87YjW2m23TuHUsxlJnzdcWCW9egAGxM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=VqqMJEvrTkB+9HnIWo9LADSoBV4iuBPWFSU1J84CsuvjLrS2s65xpKiEZRZ5ops0HEjir0p9UypHn7qmNxu+8odymDUShFL8DlFWy7if8YXuAHmYduBn4jWlzKAi0z7FYLEA0hRz1qZBqNFtGjA0F3Mh0l6xSYW6ZsnCIWfsP+A= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de; spf=pass smtp.mailfrom=linutronix.de; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=zX4dx2jw; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=OJ86VfoF; arc=none smtp.client-ip=193.142.43.55 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linutronix.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="zX4dx2jw"; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="OJ86VfoF" Date: Wed, 3 Jun 2026 12:54:48 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1780484089; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=q9bxb/X9xCVyjD49DDkQLlrOoHYB9sGX6YrLxF4sMZw=; b=zX4dx2jw3PnSZnB40E69RVUwSyhZlAZvyVGpgHrEe9IuDNLGiCQv+iGJ1WwWfLJYzPJE4z 2ZRDGnIyAI28toFzvnKeqQl/KvtXE5KFOxre8a9h2mJfc8F6SC/vRlLQv2VGMNIEE3EDT8 ie0+DGfLnjPX9ELUx2bqEiYwn09cQDkVql4qeX8c9csVZPArdAQxzO9HkFD1JhdCmSGc5q 7OeogJa4X4TIR6v8YHnMRca2OjaWQJh3DVz9TXE9eKYCQhzgBpDlu3QzN/zqauIKw3TOVm 1v09xZgpVe6B8cbPfu2oufA1tQDlr1sr4lyFw5OFEJNBTaCTn7/FcfUcmN1HpQ== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1780484089; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=q9bxb/X9xCVyjD49DDkQLlrOoHYB9sGX6YrLxF4sMZw=; b=OJ86VfoFII8HRSO1pTBegX8UtcQZe0f5sfHuRp+bdnKKlIMtiE7N02HHZIRY2QWv/kdpzA I2Sg8zARWFAMh0Dg== From: Sebastian Andrzej Siewior To: Chuyi Zhou 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() Message-ID: <20260603105448.2bwLH_XI@linutronix.de> References: <20260528151338.617843-1-zhouchuyi@bytedance.com> <20260528151338.617843-5-zhouchuyi@bytedance.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 *ma= sk, > int smp_call_function_any(const struct cpumask *mask, > smp_call_func_t func, void *info, int wait); > =20 > +#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 > =20 > +#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 =E2=80=A6 > --- 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() <=3D sizeof(unsigne= d 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 <=3D 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=3D8192 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=3D256 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 > } > =20 > /* Called by boot processor to activate the rest. */ Sebastian