From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (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 7E88D36829F; Mon, 19 Jan 2026 14:11:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.92.199 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768831890; cv=none; b=buwrtqxLKJbia67WekNB21HSSi3uaSFlmh9LoRftGzAASr5Qu+qaN68K9Z39WTQ0dy3KLzhO1c/HpZrC4QE18gX4MpTqNL377cuWcdHCCx3LujIjSGwwO949mh7VauwBZhHN8+GXGNo/Gusf3jPyWZF7/Xl2c+zJchpMnsGj+N0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768831890; c=relaxed/simple; bh=6he6bz6ClwDCplXGvfUgIs/mU1EDQVOVBTv52SThC4k=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=WbKSM43ocC9IW0SQJhR6K897SfMZ7gj1+HpjZAX7UpKJZU4w+MguTBARFhNjHhmW19AI13Ng8ieWKetczvtn3HQ3nXWT3UDerYj63BVuWjYpkM85QE0H3Hf3EZt9n3aBQ7L5rtlgdPLYLsKxyC5mvFlBti1d6GRKq85zTc7A2CI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org; spf=none smtp.mailfrom=infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=mcrVApry; arc=none smtp.client-ip=90.155.92.199 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=infradead.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="mcrVApry" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=desiato.20200630; h=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date: Sender:Reply-To:Content-ID:Content-Description; bh=6uCspkkYHZe3mdps4c7y92eawkG3ojYvKdgz01AdvO0=; b=mcrVApryCZeaZlGdULbpGCm20S 0MQ/j3elTYFI3zkqD1EU3ohRozW3DIUBTryxDsK9GFcFKe/zNADJy+oGMyXsUAboOrZKAIp6cSTBH +HALGd09FUA4MeC1djywJMa8C+w107ddgo5JRMWZpaQwlgncsf3R1tHTXW47i55Zz5bIqga0mpDoY CvokD/U65Mssy7YP63IoeSdW7lvfQQOW3ojRwCCbgKYJHBBHMdr+Yq/v2NR+JcoK6RNf68jVmvAZh ObDGFbZ8JhBggTRp3uMdE30hynasHb26RsWUAC1Io2KWAyKPA4XsRlDWwZZAw1vB6couyeMrKMoz1 Nf8AGQyQ==; Received: from 2001-1c00-8d85-5700-266e-96ff-fe07-7dcc.cable.dynamic.v6.ziggo.nl ([2001:1c00:8d85:5700:266e:96ff:fe07:7dcc] helo=noisy.programming.kicks-ass.net) by desiato.infradead.org with esmtpsa (Exim 4.98.2 #2 (Red Hat Linux)) id 1vhpyR-0000000CEfL-2ibV; Mon, 19 Jan 2026 14:11:19 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id 0124A3006CD; Mon, 19 Jan 2026 15:11:19 +0100 (CET) Date: Mon, 19 Jan 2026 15:11:18 +0100 From: Peter Zijlstra To: Shrikanth Hegde Cc: Vishal Chourasia , boqun.feng@gmail.com, frederic@kernel.org, joelagnelf@nvidia.com, josh@joshtriplett.org, linux-kernel@vger.kernel.org, neeraj.upadhyay@kernel.org, paulmck@kernel.org, rcu@vger.kernel.org, rostedt@goodmis.org, srikar@linux.ibm.com, tglx@linutronix.de, urezki@gmail.com, samir@linux.ibm.com Subject: Re: [PATCH] cpuhp: Expedite synchronize_rcu during SMT switch Message-ID: <20260119141118.GF830229@noisy.programming.kicks-ass.net> References: <20260113090153.GS830755@noisy.programming.kicks-ass.net> <20260119104739.439799-2-vishalc@linux.ibm.com> <20260119114333.GI1890602@noisy.programming.kicks-ass.net> <88f03a33-133f-44dd-bd49-395d4fa754d6@linux.ibm.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: 8bit In-Reply-To: <88f03a33-133f-44dd-bd49-395d4fa754d6@linux.ibm.com> On Mon, Jan 19, 2026 at 07:15:09PM +0530, Shrikanth Hegde wrote: > Hi Peter. > > On 1/19/26 5:13 PM, Peter Zijlstra wrote: > > On Mon, Jan 19, 2026 at 04:17:40PM +0530, Vishal Chourasia wrote: > > > Expedite synchronize_rcu() during the cpuhp_smt_[enable|disable] path to > > > accelerate the operation. > > > > > > Bulk CPU hotplug operations—such as switching SMT modes across all > > > cores—require hotplugging multiple CPUs in rapid succession. On large > > > systems, this process takes significant time, increasing as the number > > > of CPUs to hotplug during SMT switch grows, leading to substantial > > > delays on high-core-count machines. Analysis [1] reveals that the > > > majority of this time is spent waiting for synchronize_rcu(). > > > > > > > You seem to have left out all the useful bits from your changelog again > > :/ > > > > Anyway, ISTR Joel posted a patch hoisting a lock; it was a icky, but not > > something we can't live with either. > > > > Also, memory got jogged and I think something like the below will remove > > 2/3 of your rcu woes as well. > > > > diff --git a/kernel/cpu.c b/kernel/cpu.c > > index 8df2d773fe3b..1365c19444b2 100644 > > --- a/kernel/cpu.c > > +++ b/kernel/cpu.c > > @@ -2669,6 +2669,7 @@ int cpuhp_smt_disable(enum cpuhp_smt_control ctrlval) > > int cpu, ret = 0; > > cpu_maps_update_begin(); > > + rcu_sync_enter(&cpu_hotplug_lock.rss); > > for_each_online_cpu(cpu) { > > if (topology_is_primary_thread(cpu)) > > continue; > > @@ -2698,6 +2699,7 @@ int cpuhp_smt_disable(enum cpuhp_smt_control ctrlval) > > } > > if (!ret) > > cpu_smt_control = ctrlval; > > + rcu_sync_exit(&cpu_hotplug_lock.rss); > > cpu_maps_update_done(); > > return ret; > > } > > @@ -2715,6 +2717,7 @@ int cpuhp_smt_enable(void) > > int cpu, ret = 0; > > cpu_maps_update_begin(); > > + rcu_sync_enter(&cpu_hotplug_lock.rss); > > cpu_smt_control = CPU_SMT_ENABLED; > > for_each_present_cpu(cpu) { > > /* Skip online CPUs and CPUs on offline nodes */ > > @@ -2728,6 +2731,7 @@ int cpuhp_smt_enable(void) > > /* See comment in cpuhp_smt_disable() */ > > cpuhp_online_cpu_device(cpu); > > } > > + rcu_sync_exit(&cpu_hotplug_lock.rss); > > cpu_maps_update_done(); > > return ret; > > } > > > Currently, cpuhp_smt_[enable/disable] calls _cpu_up/_cpu_down > which does the same in cpus_write_lock/unlock. though it is per > cpu enable/disable one after another. > > How hoisting this up will help? By holding an extra rcu_sync reference, the percpu rwsem is kept into the the slow path, avoiding the rcu-sync on down_write(), which was very prevalent per this: https://lkml.kernel.org/r/aWU9HRcs4ghazIRg@linux.ibm.com