From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0370FEE6457 for ; Fri, 15 Sep 2023 11:46:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234347AbjIOLqy (ORCPT ); Fri, 15 Sep 2023 07:46:54 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46530 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232836AbjIOLqx (ORCPT ); Fri, 15 Sep 2023 07:46:53 -0400 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6217E1FE8 for ; Fri, 15 Sep 2023 04:46:48 -0700 (PDT) From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1694778407; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=YG5tIhlgvyo3E2tjtK9k1O7Vx/acrwOqVX1en+myyIc=; b=WQD1btgzpHrZE05x8H0EU9fVY4/RfeMU6hKI9C7seofOSQFiv36F50tKMqSmnHCLYAR6Ej YWj030j95Khtp80CzGcfGpbELdbh/q9M9WA/uF/zY9J7jRvG0Nzb0/UV5aB5Hw4HWaXn6p umHz0N3904QvLqwe3kuif5wj3zNcKtS/UveElGr/7yhmsnugbXIMh8fXooxABvymAXw2D9 gljXo9BQxITCyDzGcrdRgoR81d1C2kYGXV4AF35GCV7zLf2+9wCORUj70/A/8wgN7RDuzY 40U9aPye58ppeVjZFpizpt5RnrzS+NWS3dvU4+2egnhakP+pGdVyr0CUCtE9Hw== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1694778407; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=YG5tIhlgvyo3E2tjtK9k1O7Vx/acrwOqVX1en+myyIc=; b=jN8OWU7nyAokpykn7mI1AbzgD2mAE+5MLwjHo6zaEyL8DYNnY8lR17YZEe8DvWVaQThjqa IEnaNxCYpIjAlMDg== To: K Prateek Nayak , LKML Cc: x86@kernel.org, Tom Lendacky , Andrew Cooper , Arjan van de Ven , Huang Rui , Juergen Gross , Dimitri Sivanich , Michael Kelley , Wei Liu , Pu Wen , Qiuxu Zhuo , Sohil Mehta , Gautham Shenoy Subject: Re: [patch V4 24/41] x86/cpu: Provide cpu_init/parse_topology() In-Reply-To: <011011ee-4f83-3545-4ca2-55bc0bef284a@amd.com> References: <20230814085006.593997112@linutronix.de> <20230814085113.471353147@linutronix.de> <934072fe-eca2-44df-94e7-9fed1dc8b502@amd.com> <87r0nn8ots.ffs@tglx> <4a4d5a89-b024-ea49-8740-1f3aef412c15@amd.com> <011011ee-4f83-3545-4ca2-55bc0bef284a@amd.com> Date: Fri, 15 Sep 2023 13:46:46 +0200 Message-ID: <87led71wwp.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Prateek! On Thu, Sep 14 2023 at 14:50, K. Prateek Nayak wrote: > On 8/28/2023 7:58 PM, K Prateek Nayak wrote: > o Logical Processor : A processor core provides one or more logical > processors sharing execution resources. The > LOGICAL_PROCESSOR_ID sub-field distinguishes logical > processors in a core. The width of this bit field is > non-zero if a processor core provides more than one logical > processors. > """ > > So some questions to Intel folks to determine whether mapping AMD's > Complex to Tile makes sense or not: > > - What are the "certain resources" a group of module / tile share? > > - Module and Tile both use the phrase "set of cores" in their > description. Does this mean their existence is mutually exclusive? That's definitely a good question. > AMD's Complex (CCX) marks the L3 cache boundary. If either of the > "certain resources" refer to L3 cache, then Complex can be safely mapped > to the respective level without any fear of misinterpretation of the > characteristics. I don't think it's a good idea to try deducing cache hierarchy from the basic topology. The boundaries have changed over time and AMD has made it impossible on older CPUs to use the CPU topology for that. I tried to do that and gave up because I realized that we need both and then do the proper association by combining the information. > Also, I do not see a "DieGrp" domain in the "x86_topology_domains". Is > this because of the lack of "software visible" aspect of it despite its > possible existence? No. It's subsumed by the package domain. Let me look at the mechanics some more to make this more obvious. Thanks, tglx