From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sg-1-102.ptr.blmpb.com (sg-1-102.ptr.blmpb.com [118.26.132.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3AFA92F83B7 for ; Fri, 6 Feb 2026 11:45:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=118.26.132.102 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770378352; cv=none; b=NO/iRGPXKgHdayD4jUkfBdHwvVFfJ2Q2g0iiA45TuGZigIPEHQk9mb9bCgf4gemRklS8ImH7YK2zhO0xv1hcsJqW8HiEIzLJyNYX41NsImzxWwaIOGeDriOiPnVzsrq49PufJWAH2nCXnVLvv9IQ8wTJSuGsp2M4ljvlFnCyTLs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770378352; c=relaxed/simple; bh=foiNp3WDvIfyAqumsUEMOrAyw9J59JMY49X7S9sqVi4=; h=Mime-Version:References:In-Reply-To:Cc:From:Message-Id:To:Subject: Date:Content-Type; b=lRcr817I9po5FL+Oe5hjJgd+nf4gs0pISJtRe5ejguD5Ez7ahpWOoqcox4DGe79JHduWER2sB/c7ma+hAfQ2+gZLGWjWba6rYkW0FWH8lMv884JiuPGudzj5Kk0sHdD/I4NhqDjHn67UK45rnMKdcBNUlLs9xge6cloJoTvhp5s= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=bytedance.com; spf=pass smtp.mailfrom=bytedance.com; dkim=pass (2048-bit key) header.d=bytedance.com header.i=@bytedance.com header.b=ErHMSeO+; arc=none smtp.client-ip=118.26.132.102 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=bytedance.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=bytedance.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=bytedance.com header.i=@bytedance.com header.b="ErHMSeO+" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; s=2212171451; d=bytedance.com; t=1770378345; h=from:subject: mime-version:from:date:message-id:subject:to:cc:reply-to:content-type: mime-version:in-reply-to:message-id; bh=foiNp3WDvIfyAqumsUEMOrAyw9J59JMY49X7S9sqVi4=; b=ErHMSeO+lOU5Augis6eMfOGszvXz7TWaoh9IZpBsi0Omu8wUIluurLbMQ/udr4TAE6SRp9 5B0oK19LlX/PpU6DMeZgvw+dD93XAOjSwiQZt/630Z2I7fshaJSWFIGZerLN6GlJwGDFt4 DiB/TBveIrORBZSug4mEYft9i2UyJu/LXOmqXwTu9qCg3ycN5n0LJNEWJbMGxKuXHsAVAO 1aF7TvMFQFaSA+m1Kx46qBwbXYca9UCyoWuPkZF5KOO0XmoJnOozx1Ca1FitxkpaOCYX4o FgWzhKk09R+aEIPBOTcqWIotX6GcqlWjAOuw1Nv9VfdWJIWnB1e9hGVQoskCKw== Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260203112401.3889029-1-zhouchuyi@bytedance.com> <20260203112401.3889029-6-zhouchuyi@bytedance.com> <20260205095236.GI232055@noisy.programming.kicks-ass.net> <20260205105704.GA245049@noisy.programming.kicks-ass.net> <261ae19f-e3d1-4017-be1e-90b5c6d91dc7@bytedance.com> <20260205145912.GM2995752@noisy.programming.kicks-ass.net> <20260206094700.GR1282955@noisy.programming.kicks-ass.net> X-Lms-Return-Path: X-Original-From: Chuyi Zhou In-Reply-To: <20260206094700.GR1282955@noisy.programming.kicks-ass.net> Cc: , , , , , , , From: "Chuyi Zhou" Message-Id: Content-Transfer-Encoding: quoted-printable To: "Peter Zijlstra" Subject: Re: [PATCH 05/11] smp: Enable preemption early in smp_call_function_many_cond Date: Fri, 6 Feb 2026 19:45:14 +0800 Content-Type: text/plain; charset=UTF-8 User-Agent: Mozilla Thunderbird Hello, =E5=9C=A8 2026/2/6 17:47, Peter Zijlstra =E5=86=99=E9=81=93: > On Fri, Feb 06, 2026 at 04:43:48PM +0800, Chuyi Zhou wrote: >=20 >> However, 99% of callers have preemption disabled, some of them even >> invoking it within spin_locks (for example, we might trigger a TLB flush >> while holding pte spinlocks). >=20 > Then 99% of the callers don't benefit from this and won't see your > latency reduction -- and will be broken on PREEMPT_RT, no? Once we make the preemption logic self-contained within smp_call, the=20 disabling of preemption by most callers becomes unnecessary and can=20 therefore be removed. We can preserve the few instances where it is=20 still meaningful or apply special optimizations to them, much like the=20 subsequent patch does for arch_tlbbatch_flush/flush_tlb_mm_range. Consequently, the vast majority of callers stand to benefit. For the RT=20 kernel, this optimization provides additional benefits when smp_call is=20 invoked within spinlocks, as it reduces the length of non-preemptible=20 critical sections. We can invoke alloc_cpumask_var only when CONFIG_CPUMASK_OFFSTACK is=20 disabled, thereby avoiding broken on RT. However, using cpus_read_lock requires us to absolutely guarantee that=20 the current context is sleepable, which is difficult to ensure.