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:   Tue, 25 Oct 2022 15:35:04 +0800
From:   Feng Tang <feng.tang@intel.com>
To:     Dave Hansen <dave.hansen@intel.com>
CC:     Zhang Rui <rui.zhang@intel.com>,
        Thomas Gleixner <tglx@linutronix.de>,
        Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
        "H . Peter Anvin" <hpa@zytor.com>,
        Peter Zijlstra <peterz@infradead.org>, <x86@kernel.org>,
        <linux-kernel@vger.kernel.org>, <tim.c.chen@intel.com>,
        Xiongfeng Wang <wangxiongfeng2@huawei.com>,
        <liaoyu15@huawei.com>
Subject: Re: [PATCH v1 1/2] x86/tsc: use logical_package as a better
 estimation of socket numbers
Message-ID: <Y1eRqOZIRYtC7ZAE@feng-clx>
References: <20221021062131.1826810-1-feng.tang@intel.com>
 <f27e4b3f858890c657df9a7d6f34dc2d60b89757.camel@intel.com>
 <63dca468-c94d-844a-5b19-09c03cf84911@intel.com>
 <6636557f617ea5a1a1ab6f30f7aea0ececdd2a36.camel@intel.com>
 <dfd2fb43-2a19-545a-fea8-f793a685ef30@intel.com>
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <dfd2fb43-2a19-545a-fea8-f793a685ef30@intel.com>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?7x8xbO/9IgviBUfL7OZiR4vBOY9P7DHIQ0R9BtYBbSgjmvPc004EM7v159ko?=
 =?us-ascii?Q?f8GGI5/s0b2ibEiUe+KIMAX8jKIoQvSUE77tVZLGAMHvx4sXs7s7/Q823GtF?=
 =?us-ascii?Q?EINFrvx91LnUsUOBkEmFHpvdwi3iWfYyJfbf4RudyTU1rkcF5ROTlQbMpNQi?=
 =?us-ascii?Q?8PHdMuCnc6hdgqbEOlKaNvygqAu8A0bRpi2WVhDdW62DHiKsQ7B4kbrYQ5Bh?=
 =?us-ascii?Q?JAm2PtCc0CqZc3Ev1iHf1ig0/IAm3osK+7uLyjG/eIBG7uKULla4AVudLwG5?=
 =?us-ascii?Q?1UrpapuMAweJyutZORcAnQ8Ucp+jPzn32A0/clY2/szVkMhp5ZfV/b9/pnAw?=
 =?us-ascii?Q?20b4V0zjA9/Xi9uc5jZDQWvWDDwPLJZAUJ0S9O0wkyjUEeq4aRxC1lE5yq71?=
 =?us-ascii?Q?TJRMmIrOFrJOEn7+OK8J6wRb0GiW/pT5fF5GDaoJoU2IztHss0DnqKzt9wma?=
 =?us-ascii?Q?AiCyM/t9OCm3gJegjKS205pmhjbv1Kam7rG+S+YmJN2EqFskVCj2YPfARlb+?=
 =?us-ascii?Q?xh1qasXk4caoM/N2nSja/qFhJUNPkXokEB/BBA0iS8VtSp4OC3vn37bUrV1I?=
 =?us-ascii?Q?LLM3m0JpOXiHxm7mBgiWkFejh4PbtKfrmqp9n0DrHozbMkcZV5D6b8ozzvyT?=
 =?us-ascii?Q?d0Q4MMHwOevfOE8ot7gJ1+hMNz5Qufb99v2TtdTkmBX/KRFC5uPMeqJOeMXB?=
 =?us-ascii?Q?3I5lBVuzyMIfn1JtdZ+6HahZA2+1gFwMkvYG+JguNHsZWHvpmvyiE0aRnFlq?=
 =?us-ascii?Q?yxsuFsxeuUKxJLo96h+TWcamXcqiiHmeivNt08VNOzgMytpyXqLh/RvwrkSi?=
 =?us-ascii?Q?cgz5NsoOdsGudKwGIuR6qVFujI0xv52hgOQV4UVxhRbF1hwyMvLOLEOTklxt?=
 =?us-ascii?Q?lFXX5PYNA4IV4H1mYUqOSYJhIBetienMzrn5vl2cLVJMUI+zOMMv6yu/7HQZ?=
 =?us-ascii?Q?n2PJSt5PVcinBG9TY9QrfSw5gbgn0zhI0dj3kCetRqT0fknipg7sb+YozP05?=
 =?us-ascii?Q?kTuWOvUk4RWphAirXqnEwQCsWAPnUsySK6JePt+tq79+iHxh7qBxs1+P+Fi0?=
 =?us-ascii?Q?J7I4h3t8fF/bVSra4cYA5Kcn6FsxBFBPVQ5laMPJHXyzugAQ2YAdVPxn8Ue/?=
 =?us-ascii?Q?QonhV9/j1dWwUppBDt9pElbpgQcNv5JYdpiIoavtVVc0kteF8Rxmhl6ID08n?=
 =?us-ascii?Q?Tup+XPp9oJb6XcA/ib34xLP3Xa7rYTau2/h31hN4agbl5KYh+sj7dQAacB1b?=
 =?us-ascii?Q?idO9eAnHHsDq7mZQXu3dZXI646+e52NTM6oNbeK9UrrEH2OAANPM8jlwduUu?=
 =?us-ascii?Q?Iw1xznuFaOaVWoG9bjrP76p/TZtqA3/Me0o9NnLA20Br2Q04OR+MX/mdQJXt?=
 =?us-ascii?Q?W7Qrt79HDYK5Eytpumj7rv3dcdA8yZF2NJ6NJ87oPocKiFBV8EU3V8vFawOb?=
 =?us-ascii?Q?g3buDkO3r4RWYyv5niBlwB0evxK98//FmVo1sXBuXMMeKAvWDmypRA53exMF?=
 =?us-ascii?Q?uYZIhPJ+pPiwH312MqWcDc4sQS5LMIjkJUg9kjcz+BXPxCfkjvvaMKARC34X?=
 =?us-ascii?Q?TZ2XvbV6c8lNEH7xUdbd8tXxo9u0XKEbcCF50Ahv?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 0544ba80-0ac6-4511-c92a-08dab65b7559
X-MS-Exchange-CrossTenant-AuthSource: MN0PR11MB6304.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Oct 2022 07:35:15.5006
 (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: 9o3QjSSDz1iijgZ0+isImqf492D+kpZ/kE2ZfCdaILsjivXQuK7hxGzsi4A+DO8Jq1zzyojf2cz0/O9TX09a0g==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY5PR11MB6257
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-4.9 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,
        SPF_HELO_NONE,SPF_NONE,URIBL_BLOCKED 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 Mon, Oct 24, 2022 at 08:42:30AM -0700, Dave Hansen wrote:
> On 10/22/22 09:12, Zhang Rui wrote:
> >>> I'm not sure if we have a perfect solution here.
> >> Are the implementations fixable?
> > currently, I don't have any idea.
> > 
> >>   Or, at least tolerable?
> 
> That would be great to figure out before we start throwing more patches
> around.

Yes, agreed!

> >> For instance, I can live with the implementation being a bit goofy
> >> when
> >> kernel commandlines are in play.  We can pr_info() about those cases.
> > My understanding is that the cpus in the last package may still have
> > small cpu id value. This means that the 'logical_packages' is hard to
> > break unless we boot with very small CPU count and happened to disable
> > all cpus in one/more packages. Feng is experiencing with this and may
> > have some update later.
> > 
> > If this is the case, is this a valid case that we need to take care of?
> 
> Well, let's talk through it a bit.
> 
> What is the triggering event and what's the fallout?

In worst case (2 sockets), if the maxcpus falls to '<= total_cpus/2',
the 'logical_packages' will be less than the real number.

> Is the user on a truly TSC stable system or not?
> 
> What kind of maxcpus= argument do they need to specify?  Is it something
> that's likely to get used in production or is it most likely just for
> debugging?

IIUC, for the server side, it's most likely for debug use. And for
clients, socket number is not an issue.

> What is the maxcpus= fallout?  Does it over estimate or under estimate
> the number of logical packages?
 
Only under estimate.

> How many cases outside of maxcpus= do we know of that lead to an
> imprecise "logical packages" calculation?
 
Thanks to you, Peter and Rui's info, we have listed a bunch of
user cases than 'maxcpus', and they won't lead to imprecise
'logical_packages'. And I'm not sure if there is other case which
hasn't poped up.

> Does this lead to the TSC being mistakenly marked stable when it is not,
> or *not* being marked stable when it is?

Only the former case 'mistakenly marked stable' is possible, say we
use 'maxcpus=8' on a 192 core 8 sockets machine.

> Let's get all of that info in one place and make sure we are all agreed
> on the *problem* before we got to the solution space.

OK.

Thanks,
Feng