Received-SPF: pass (google.com: domain of linux-kernel+bounces-130950-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Date: Thu, 4 Apr 2024 13:08:56 +0800
From: Feng Tang <feng.tang@intel.com>
To: "Paul E. McKenney" <paulmck@kernel.org>
CC: <linux-kernel@vger.kernel.org>, <x86@kernel.org>, Zhengxu Chen
	<zhxchen17@meta.com>, Danielle Costantino <dcostantino@meta.com>, "Thomas
 Gleixner" <tglx@linutronix.de>, Ingo Molnar <mingo@redhat.com>, "Borislav
 Petkov" <bp@alien8.de>, Dave Hansen <dave.hansen@linux.intel.com>, "H. Peter
 Anvin" <hpa@zytor.com>, Peter Zijlstra <peterz@infradead.org>, Waiman Long
	<longman@redhat.com>, John Stultz <jstultz@google.com>, Boqun Feng
	<boqun.feng@gmail.com>, Neeraj Upadhyay <Neeraj.Upadhyay@amd.com>
Subject: Re: [PATCH RFC v2 tsc] Check for sockets instead of CPUs to make
 code match comment
Message-ID: <Zg416EXHJa9CdI9L@feng-clx.sh.intel.com>
References: <62a0a0cd-3103-4e8f-b4c8-a91f12121e92@paulmck-laptop>
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <62a0a0cd-3103-4e8f-b4c8-a91f12121e92@paulmck-laptop>
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?lJ8tEOqlgfrDzPZbftJnz498Rzd76Okud+h+/v7ZspESa7YLAFyUrOKR09kS?=
 =?us-ascii?Q?7jFm6b9VNY8xgTYvRV8M93GY/3pchNywj+oeCtcd4w5nVhyPrPfzMuUdlCG8?=
 =?us-ascii?Q?vu9GD6+vNK7wOsu16uF42EsMIBahqgtChMUgdi9BA8R8ERU1WGQocbzIFSri?=
 =?us-ascii?Q?3Q57nIpRa5DBpxygvx4vf4xqZ09nh1yck8vZuVC8FtzA7VbSlUzzvXm2sFu9?=
 =?us-ascii?Q?ZGXv1U48Eo/ZBNenmq3HKrry70zyWXbzHPlFd02SAIkcyzxLgzhHHU79s0/A?=
 =?us-ascii?Q?nJBnssgCdkGVTcdmNG+cVLTtGwD6eFwDw9qkYUR48vVxpVQpBO9CEjebkA3M?=
 =?us-ascii?Q?lkHaNyMxaL7gyXmXfpFzlsdDCAJ6ycQCPIJzfbgXb2+TBLClw3IEpeNa4FB5?=
 =?us-ascii?Q?9S/t17Tt2Hd7H2yJs3v7crlAQh0x520cjyEEfUyTGcjMuMZd7ZbPoDlhh+yi?=
 =?us-ascii?Q?ac+dp+oHMmxWfXd5a7KZc25e94cNaCYKnOsAIGMbKg1LBuCADG1WSwcosqFd?=
 =?us-ascii?Q?Zt/dfCQ78TSQgCh73d3xz2DmOXTt2up+5bNcMdj5bQIFvXXI/BMVYIpjgVSX?=
 =?us-ascii?Q?lzQy1L2lWZRBKXDuS3EWekmJkmEcZGP+hCV6yVKO2qgL4/8zpN+/DGt5MHV2?=
 =?us-ascii?Q?BfiNL68ieqoSEwN4cSOmjFe2QU+G7p3VY/TLO1hPZ+L5iFtTY6SlHHlVxo5S?=
 =?us-ascii?Q?V3xTeFHoWSAL5XxAzk1JSMlg/SAarfAly8hTzqwuqGuCr3MiH7u8vnwJ9Tge?=
 =?us-ascii?Q?N6f2byX4HP7QKRmPid79Q1TU45mr75xweuaRYPekiDME1wcVwmdlCqml+x9M?=
 =?us-ascii?Q?oYpdmJhYldB/kXMqyyePn3hvRSXakp0M2ljUZAT1IK7kSG4TfSUYJpeU/i6e?=
 =?us-ascii?Q?gDWMF6/YPwCBNp/YWK6dKmdzam3+xlwuiW4VoGCzJXe9G2deueQkRKhMPJDN?=
 =?us-ascii?Q?puU1zu9drEWw5JEww0G4oAlOm+jmYf5+4/K+amiFOV3iPW2vaPah3ALwzoL7?=
 =?us-ascii?Q?Qkq4HuNe3O/n9BOP2u2rnV8VgPciHOnmOhGFSdLNRGKNA5MLpqz7Z3cDdKII?=
 =?us-ascii?Q?MXX/6I/O5tGcvQJw56WmZoAEWCnBVMh816Tyox6LGGPR2AF8KWrSUnZCdtVO?=
 =?us-ascii?Q?9sZs2OoUpw3lPmSlWT4JLXLafOuRVFv+2trGiux1UzgMlAKtv+CoyYe1ulx/?=
 =?us-ascii?Q?M/eAR37JlcTBw+HI7ESE5VU3rbdMm74HfZhCl3HharS6AkInzNBEYsERw7W1?=
 =?us-ascii?Q?+Uf1gJAEIzbSv7nLt7OMOoDEra3+2KnAuAkO1h1UXxf4v4B2/tx81NCcNwZJ?=
 =?us-ascii?Q?YcoPq6th1fGBKuPzRtV7O6w5y7V93nxBgydGlR/rbo5irenk224t+3uq/IfC?=
 =?us-ascii?Q?lNdNZdhRfWa6BjMKU7pu6ioQwZ7XfeFBRla79zpOKu5sSS0+5PknhaRGm3ld?=
 =?us-ascii?Q?EpGrEIvkcp/wizhpRmjRpWovIMql9VGJyYBpJhGvKeWPEuIpL9ap2jJVqLuz?=
 =?us-ascii?Q?2NYZ7C5AVaLkdxD/CLWaqAPT8iKuF/3E88OagBCCA8Mpd9BnY8I1cQcsh4yZ?=
 =?us-ascii?Q?EMKEONT5OsC80dH/s0kKvVrz83QOt7IxNXAezFp8?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 7a58eacd-a46a-40c6-6b38-08dc54677429
X-MS-Exchange-CrossTenant-AuthSource: MN0PR11MB6304.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Apr 2024 05:24:08.8951
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: YAR6fMpT6V3s6yI0aQH+KeRsJFXEYlIykrVmRs6EIyKrUDCoHiuB5lKPEIYpdG7OgzDeIOFuMyYGwLadDLDldA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR11MB7303
X-OriginatorOrg: intel.com

On Wed, Apr 03, 2024 at 12:10:41PM -0700, Paul E. McKenney wrote:
> The unsynchronized_tsc() eventually checks num_possible_cpus(), and
> if the system is non-Intel and the number of possible CPUs is greater
> than one, assumes that TSCs are unsynchronized.  This despite the
> comment saying "assume multi socket systems are not synchronized",
> that is, socket rather than CPU.  This behavior was preserved by
> commit 8fbbc4b45ce3 ("x86: merge tsc_init and clocksource code") and
> by the previous relevant commit 7e69f2b1ead2 ("clocksource: Remove the
> update callback").
> 
> The clocksource drivers were added by commit 5d0cf410e94b ("Time: i386
> Clocksource Drivers") back in 2006, and the comment still said "socket"
> rather than "CPU".
> 
> Therefore, bravely (and perhaps foolishly) make the code match the
> comment.
> 
> Note that it is possible to bypass both code and comment by booting
> with tsc=reliable, but this also disables the clocksource watchdog,
> which is undesirable when trust in the TSC is strictly limited.
> 
> Changes since v1:
> 
> o	Forward-port to v6.9-rc1.
> 
> Reported-by: Zhengxu Chen <zhxchen17@meta.com>
> Reported-by: Danielle Costantino <dcostantino@meta.com>
> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: Borislav Petkov <bp@alien8.de>
> Cc: Dave Hansen <dave.hansen@linux.intel.com>
> Cc: "H. Peter Anvin" <hpa@zytor.com>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Feng Tang <feng.tang@intel.com>
> Cc: Waiman Long <longman@redhat.com>
> Cc: John Stultz <jstultz@google.com>
> Cc: Neeraj Upadhyay <Neeraj.Upadhyay@amd.com>
> Cc: <x86@kernel.org>
> 
> diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c
> index 5a69a49acc963..e938b990bea19 100644
> --- a/arch/x86/kernel/tsc.c
> +++ b/arch/x86/kernel/tsc.c
> @@ -1289,7 +1289,7 @@ int unsynchronized_tsc(void)
>  	 */
>  	if (boot_cpu_data.x86_vendor != X86_VENDOR_INTEL) {
>  		/* assume multi socket systems are not synchronized: */
> -		if (num_possible_cpus() > 1)
> +		if (nr_online_nodes > 1)

Regarding package/socket number, Thomas' topology refactoring patchset
(merged in 6.9-rc1) makes topology_max_packages() more accurate than
nr_online_nodes(), more details in https://lore.kernel.org/lkml/20240327025105.2861341-1-feng.tang@intel.com/

Thanks,
Feng