Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Wed, 12 Oct 2022 16:44:05 +0800
From:   Feng Tang <feng.tang@intel.com>
To:     Peter Zijlstra <peterz@infradead.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Dave Hansen <dave.hansen@intel.com>
CC:     Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
        "H . Peter Anvin" <hpa@zytor.com>, <x86@kernel.org>,
        <linux-kernel@vger.kernel.org>, <rui.zhang@intel.com>,
        <tim.c.chen@intel.com>, Xiongfeng Wang <wangxiongfeng2@huawei.com>,
        Yu Liao <liaoyu15@huawei.com>
Subject: Re: [PATCH] x86/tsc: Extend the watchdog check exemption to 4S/8S
 machine
Message-ID: <Y0Z+VR9MnASeOA3S@feng-clx>
References: <20221009051209.393377-1-feng.tang@intel.com>
 <Y0LGLGW7RSlklKyl@hirez.programming.kicks-ass.net>
 <Y0N0ENurfliW315D@feng-clx>
 <aff10f33-b379-6872-f180-b38f6a0a669a@intel.com>
 <Y0TCOKc7n38341eJ@feng-clx>
 <Y0UgeUIJSFNR4mQB@feng-clx>
 <Y0VpG8POb4AL1g33@hirez.programming.kicks-ass.net>
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <Y0VpG8POb4AL1g33@hirez.programming.kicks-ass.net>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?J/S9dAg//ifCNMyZjnuJi0CUFDEq7YEmQZYmjsAsjFz5LBZ4f65ndKYeq1u4?=
 =?us-ascii?Q?iYxGDvQyCtZnW+zgH86W/xcy4Rublc/BSwXso8kiV9c6OdiZ1dMw4+hk7hTE?=
 =?us-ascii?Q?RkzhyCAaXrgeKutjIfP2GsBkxCLmwHlebgkxX9woSVgBs6/nRf6yCmQL4dcM?=
 =?us-ascii?Q?tVBtv3xicFkYW1gDTCW8aevKQGtE10uAib1Epq1Dru3+SCyIV9mJxv9/VEmO?=
 =?us-ascii?Q?RXwFuEsFY8MablxFWLTIkuTLjsB/YmaYkREeduXyAUIlRVrz3LLdvZ//g7dz?=
 =?us-ascii?Q?AoLv0sQDq/MB/+gWAALQ/jLcYa7SgO9qMCBw2sBxqqUrntEr6Ic63va3PvXc?=
 =?us-ascii?Q?p5FFwAcKdutmCYGxpaFBVQmKFJ+EjHkLBdEbfdvc1pWQVLmEvyDck4+IZ8gq?=
 =?us-ascii?Q?SA3wVze9a/GE9XgWEGVmYTNVoPalxkdO6viJWaRxi08Wc4k5u0FApKd5eOYm?=
 =?us-ascii?Q?fU58ECLCAd2ThpvMaCRT1TXPDnVV73ezR9TaDLVv0A8A7dSFp3O2AzWhniPB?=
 =?us-ascii?Q?bOmjEh5ORRITY83CKifxRRFWqo+BVW+6/BdfjX9ZOo3KZvwa841TYH7qOjwT?=
 =?us-ascii?Q?eTOSX6kQzyuYxSSRU4/mj348qKaZxQ25BGBEil/Gga0+s5QAutSt7dxEmbco?=
 =?us-ascii?Q?jtG6KFCWCK//NbilaMH+j61UHdAllS8sXMpuQLpPksNR/9SU6+xDGDzWOoy5?=
 =?us-ascii?Q?Uyqhvs9fMRJaJmBdBL0d01DSF53sBJgJe/gsBUQu2kelrirI/TVCNGDmFh26?=
 =?us-ascii?Q?YUuLXBVrBykhQveUv6fmjtYtLI4WAzyB8/QZbkN1mdjhG1Vab5TXJu6t6Jrd?=
 =?us-ascii?Q?vSlhfPPqJJB60pm9EtB5IEUg2eLN2Y1wqm6Z8YPZ1OrLdoSK4K26GzbOk5r/?=
 =?us-ascii?Q?pHObz2WrekmTUQDUpkWHKS0Gsz+wWCqhQ0mHqhgToeq18az6sGN35JVc8WTk?=
 =?us-ascii?Q?KsxVO7qLm+qMdbqlzutVqdC+nGcJ2Rqqs3CCmY0AhG3YSkiAW7m5cMRQmDaN?=
 =?us-ascii?Q?dzGzDZ5XGEhJSoYZdnFier4/Yq2J2hQGUSaM/clc5OrCp2ViyZWWDH2wgGXU?=
 =?us-ascii?Q?Km3+tFfDcS6BoBiRU42YdNhUy1Z9oziV9jlPn3/ccvOfIPVBjvI7erTJ1uGk?=
 =?us-ascii?Q?W/zcH+j2TZm8MGYYSTVV0BOlPXofBut1wW46dgj6GBi8F4KAR9yv+fr6yU83?=
 =?us-ascii?Q?VvOR87ASB5Al5HYxbOEw8DkQrv59pXckh6ZPWdgq7Wu+ZMclWP9x80hhNpUR?=
 =?us-ascii?Q?ueMttkWLNWgx2c4P5H6vlbMVdd4AAkThg4WqGZtOmfgMn5Op4dfNo4nI3+ZK?=
 =?us-ascii?Q?bDiEJa5uC0DssjSlS073KeYkP99EEjkBRedZfK/MLoXfMnI11Sk7Hc4InIhd?=
 =?us-ascii?Q?qlF1SjDNCp9/cB6Vun5HFjJQhCfpIqbN+3S1oalyKbPh7NZB3t4GwHhkDiho?=
 =?us-ascii?Q?t4aB9YUi3JAPubC1q+EYe7XZsU/XwgXIZ1eczacW2/JCQsijDudg61Nu3wFV?=
 =?us-ascii?Q?9tEnq0TWU4E7dtlKQbuwQaljSs6EAjDZNN08XkCbiCjxCqtwwLAaID/Z/8PM?=
 =?us-ascii?Q?dzEqoC8VnS/Hxa8owykxhZSoH+Qh+fLU5T8I8PRR?=
X-MS-Exchange-CrossTenant-Network-Message-Id: b9f4382b-2d54-4092-e7fb-08daac2df79d
X-MS-Exchange-CrossTenant-AuthSource: MN0PR11MB6304.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Oct 2022 08:44:25.5734
 (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: fC95vSVpKvN0gwriDXNuj4PUg9kllaDQcM24tSfEkP/N6q6k3xBQAqdQLqukUsRh62zNoZRI2vmYKTgrYq8Tdg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL3PR11MB5699
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI,
        SPF_HELO_NONE,SPF_NONE autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Tue, Oct 11, 2022 at 03:01:15PM +0200, Peter Zijlstra wrote:
> On Tue, Oct 11, 2022 at 03:51:21PM +0800, Feng Tang wrote:
> > Th simple patch below is to have a dedicate CPU nodemask and set it in
> > early SRAT CPU parsing, still it has problem when sub-numa is enabled
> > in BIOS where there are more NUMA nodes in SRAT table. (also I'm
> > not sure the change to amdtopology.c is right)
> 
> No; none of this has anything to do with nodes. This is about sockets.

Exactly. All we try to do is to get a closer number to the socket
numbers (also stated in current code comments)

According to our discussion, we haven't found a way to get a very
accurate number of sockets, so I plan to (if no objection):

* Send a patch lifting the socket number check from 2 to 4, to fix
  the issue reported by Yu Liao.

* Send another RFC patch[1], which makes the socket number more
  accurate, as it solve the 2 problems mentioned by Dave:
  - fakenuma (numa=fake=4 etc)
  - system with CPU-DRAM nodes + HBM nodes + Persistent Memory nodes
  but it still can't cover the subnuma enabled case 

[1]. https://lore.kernel.org/lkml/Y0UgeUIJSFNR4mQB@feng-clx/

Thanks,
Feng