From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 DC7FD26F2BE for ; Fri, 26 Jun 2026 13:49:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782481770; cv=none; b=rZic4+D1GdG8sRXERBELHGyyVmzKwI0iG07Me85Y5rSoasBnCvz9joS1yj/8BLO91XRh5hfShe8mh2jlIK6xz5ii9GMLw+UE3UsuVPNV4y4h0ZAFaG4rGG3jf1NN1tcNjwm9HrKlO2BKTgPKwEw33HYWqVxmh+KbKrqe08k5XzQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782481770; c=relaxed/simple; bh=1CVJ7Rek5Q4LS0m/JmaUV1QDrg6AogSZObrwRyjUUm0=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=epgT2JX9+L17i2jAVONBFS2o5Q7ySs/IXG6JeKW5cNzrP95QNwLJ8z2CGgpaWz2zlq/n/BsZRUvELIINDidaEQxLAKdttMmjH7LMnuFoApWUwKGGOTF86987eQD/ltFxpYuuUMDl7AjTncQ7QG3hVpGzF89nDpGSdTevEzWqwX8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=fyDcHWkZ; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="fyDcHWkZ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C7CC21F000E9; Fri, 26 Jun 2026 13:49:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1782481769; bh=9SyJHv7wqpz+S5mHoigxyJTNvMffZOeKwThpBFPw28k=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=fyDcHWkZKFz1T71xnnPkUm6jE0F4npGiGStIQLp5K68WHn41YqGLVlMO8luqdKFga bMSkDZONiBcAAZFSD5xWhqr5b6utYliF7EQWamySEMfgqqZBXMIItQYZepa0+RdSZi pFjYk5xN5lKHqIUBimDyc990C547Nf0NUr9RLh56PWk1gBlECfuHOUaZtm7L11wMpk kjcTMnyLYTXYj+k3X+8J2kuHPtyHMmMIYmz7jzG4mUyJVkSfsC3OdlpO6w3yWslF3L QI/bKSsG5WkPJ9s8yCOXU8W3gheSh112O7kb5oYrXTmjhlphzIG4/iU5aHDsTtg0eV 94WynbsRph12w== From: Thomas Gleixner To: Chuyi Zhou , 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, bigeasy@linutronix.de, clrkwllms@kernel.org, rostedt@goodmis.org, nadav.amit@gmail.com, vkuznets@redhat.com Cc: linux-kernel@vger.kernel.org, Chuyi Zhou Subject: Re: [PATCH v8 03/14] smp: Refactor remote CPU selection in smp_call_function_any() In-Reply-To: <20260616111127.966468-4-zhouchuyi@bytedance.com> References: <20260616111127.966468-1-zhouchuyi@bytedance.com> <20260616111127.966468-4-zhouchuyi@bytedance.com> Date: Fri, 26 Jun 2026 15:49:26 +0200 Message-ID: <874iipjtsp.ffs@fw13> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain On Tue, Jun 16 2026 at 19:11, Chuyi Zhou wrote: > Currently, smp_call_function_any() disables preemption across the entire > process of picking a target CPU, enqueueing the IPI, and synchronously > waiting for the remote CPU. Since smp_call_function_single() has already > been optimized to re-enable preemption before the synchronous > csd_lock_wait(), callers of smp_call_function_any() should also benefit > from this optimization to reduce the preemption-disabled critical section. > > A naive approach would be to simply remove get_cpu() and put_cpu() from > smp_call_function_any(), leaving the preemption disablement entirely to > smp_call_function_single(). However, doing so opens a dangerous > preemption window between picking the remote CPU (e.g., via > sched_numa_find_nth_cpu()) and dispatching the IPI inside > smp_call_function_single(). If the selected remote CPU is fully offlined > during this window, smp_call_function_single() will fail its > cpu_online() check and return -ENXIO directly to the caller, violating > the guarantee to execute on *any* online CPU in the mask. > > To safely enable this optimization, this patch refactors the logic of s/this patch// > smp_call_function_any() and smp_call_function_single(). By moving the > random remote CPU selection into a common __smp_call_function_single(), > and keep the entire selection and IPI dispatch process within a single > preemption-disabled region. This is actually a nice comprehensible change log. > +static int __smp_call_function_single(int cpu, smp_call_func_t func, > + void *info, const struct cpumask *mask, int wait) Please align the second row argument with the first argument of the row above. See Documentation. And while at it please make 'wait' bool because it _is_ a boolean flag. > + > +/** > + * smp_call_function_single - Run a function on a specific CPU > + * @cpu: Specific target CPU for this function. > + * @func: The function to run. This must be fast and non-blocking. > + * @info: An arbitrary pointer to pass to the function. > + * @wait: If true, wait until function has completed on other CPUs. While at it please align the argument descriptors tabular. This zigzag is harder too read. See documentation. > + * > + * Returns: %0 on success, else a negative status code. > + */ > +int smp_call_function_single(int cpu, smp_call_func_t func, void *info, > + int wait) bool wait and no line break required.