From: K Prateek Nayak <kprateek.nayak@amd.com>
To: Thomas Gleixner <tglx@linutronix.de>,
LKML <linux-kernel@vger.kernel.org>
Cc: x86@kernel.org, Tom Lendacky <thomas.lendacky@amd.com>,
Andrew Cooper <andrew.cooper3@citrix.com>,
Arjan van de Ven <arjan@linux.intel.com>,
Huang Rui <ray.huang@amd.com>, Juergen Gross <jgross@suse.com>,
Dimitri Sivanich <dimitri.sivanich@hpe.com>,
Michael Kelley <mikelley@microsoft.com>,
Wei Liu <wei.liu@kernel.org>, Pu Wen <puwen@hygon.cn>,
Qiuxu Zhuo <qiuxu.zhuo@intel.com>,
Sohil Mehta <sohil.mehta@intel.com>,
Gautham Shenoy <gautham.shenoy@amd.com>
Subject: Re: [patch V4 24/41] x86/cpu: Provide cpu_init/parse_topology()
Date: Thu, 14 Sep 2023 14:50:45 +0530 [thread overview]
Message-ID: <011011ee-4f83-3545-4ca2-55bc0bef284a@amd.com> (raw)
In-Reply-To: <4a4d5a89-b024-ea49-8740-1f3aef412c15@amd.com>
Hello Thomas,
On 8/28/2023 7:58 PM, K Prateek Nayak wrote:
> Hello Thomas,
>
> On 8/28/2023 3:35 PM, Thomas Gleixner wrote:
>> Prateek!
>>
>> On Mon, Aug 28 2023 at 11:37, K. Prateek Nayak wrote:
>>> On 8/14/2023 2:24 PM, Thomas Gleixner wrote:
>>>
>>> Since these enums come from the description of level type of CPUID leaf
>>> 0x1f, can we have a short description clarifying what each signify. This
>>> will also help clarify the mappings for AMD's extended CPUID leaf
>>> 0x80000026 (specifically for CCX and CCD level types). I had following
>>> in my mind:
>>
>> Makes sense.
>>
>>> TOPO_MODULE_DOMAIN,
>>> + /*
>>> + * If exists, represents a group of tiles within
>>> + * an instance of the next domain
>>> + *
>>> + * On Intel: This level contains a group of Tile
>>> + * type as described by CPUID leaf 0x1f
>>> + *
>>> + * On AMD: This is the group of "Complex" type
>>> + * instances as described by CPUID leaf
>>> + * 0x8000_0026
>>> + */
>>> TOPO_TILE_DOMAIN,
>>> + /*
>>> + * If exists, represents a group of dies within an
>>> + * instance of the next domain
>>> + *
>>> + * On Intel: This level contains group of Die
>>> + * type as described by CPUID leaf 0x1f
>>> + *
>>> + * On AMD: This is the group of "CCD (Die)"
>>> + * type instances as described by CPUID leaf
>>> + * 0x8000_0026
>>> + */
>>> TOPO_DIE_DOMAIN,
>>> + /*
>>> + * If exists, represents a group of packages
>>> + * within the root domain
>>> + */
>>> TOPO_PKG_DOMAIN,
>>> + /* Topmost domain with a singular instance */
>>> TOPO_ROOT_DOMAIN,
>>> TOPO_MAX_DOMAIN,
>>> };
>>
>> Now this begs the obvious question what the actual meaning of these
>> domains is and what's their relevance for the kernel.
>>
>> It's probably undisputed what SMT/CORE mean and what their relevance is.
>> The PKG/DIE domains are pretty clear too.
>
> Yup! Those seem to be clear.
>
>>
>> Now we have:
>>
>> MODULE (Intel only)
>>
>> TILE Intel, AMD names it "Complex"
>
> So here is my interpretation of 0x1f since I could not find much in the
> SDM for these level types.
Turns out, there is indeed more information about these types in SDM.
Intel SDM Vol. 3A, in Sec. 9.9.1 "Hierarchical Mapping of Shared
Resources" contains description of these level. I'll quote it here for
ease of readers:
"""
The decomposition of an APIC_ID may consist of several sub fields
representing the topology within a physical processor package, the
higher-order bits of an APIC ID may also be used by cluster vendors to
represent the topology of cluster nodes of each coherent multiprocessor
systems:
o Cluster : Some multi-threading environments consists of multiple
clusters of multi-processor systems. The CLUSTER_ID
sub-field is usually supported by vendor firmware to
distinguish different clusters. For nonclustered systems,
CLUSTER_ID is usually 0 and system topology is reduced.
o Package : A physical processor package mates with a socket. A package
may contain one or more software visible die. The PACKAGE_ID
sub-field distinguishes different physical packages within a
cluster.
o Die : A software-visible chip inside a package. The DIE_ID
sub-field distinguishes different die within a package. If
there are no software visible die, the width of this bit
field is 0.
o DieGrp : A group of die that share certain resources.
o Tile : A set of cores that share certain resources. The TILE_ID
sub-field distinguishes different tiles. If there are no
software visible tiles, the width of this bit field is 0.
o Module : A set of cores that share certain resources. The MODULE_ID
sub-field distinguishes different modules. If there are no
software visible modules, the width of this bit field is 0.
o Core : Processor cores may be contained within modules, within
tiles, on software-visible die, or appear directly at the
package domain. The CORE_ID sub-field distinguishes
processor cores. For a single-core processor, the width of
this bit field is 0.
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?
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.
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?
> [..snip..]
--
Thanks and Regards,
Prateek
next prev parent reply other threads:[~2023-09-14 9:21 UTC|newest]
Thread overview: 85+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-14 8:53 [patch V4 00/41] x86/cpu: Rework the topology evaluation Thomas Gleixner
2023-08-14 8:53 ` [patch V4 01/41] x86/cpu/hygon: Fix the CPU topology evaluation for real Thomas Gleixner
2023-08-14 8:53 ` [patch V4 02/41] cpu/SMT: Make SMT control more robust against enumeration failures Thomas Gleixner
2023-08-15 21:15 ` Dave Hansen
2023-10-10 12:18 ` Thomas Gleixner
2023-10-13 9:38 ` [tip: x86/core] " tip-bot2 for Thomas Gleixner
2023-08-14 8:53 ` [patch V4 03/41] x86/apic: Fake primary thread mask for XEN/PV Thomas Gleixner
2023-10-13 9:38 ` [tip: x86/core] " tip-bot2 for Thomas Gleixner
2023-08-14 8:53 ` [patch V4 04/41] x86/cpu: Encapsulate topology information in cpuinfo_x86 Thomas Gleixner
2023-10-13 9:38 ` [tip: x86/core] " tip-bot2 for Thomas Gleixner
2023-08-14 8:53 ` [patch V4 05/41] x86/cpu: Move phys_proc_id into topology info Thomas Gleixner
2023-10-13 9:38 ` [tip: x86/core] " tip-bot2 for Thomas Gleixner
2023-08-14 8:53 ` [patch V4 06/41] x86/cpu: Move cpu_die_id " Thomas Gleixner
2023-10-13 9:38 ` [tip: x86/core] " tip-bot2 for Thomas Gleixner
2023-08-14 8:53 ` [patch V4 07/41] scsi: lpfc: Use topology_core_id() Thomas Gleixner
2023-10-13 9:38 ` [tip: x86/core] " tip-bot2 for Thomas Gleixner
2023-08-14 8:53 ` [patch V4 08/41] hwmon: (fam15h_power) " Thomas Gleixner
2023-10-13 9:38 ` [tip: x86/core] " tip-bot2 for Thomas Gleixner
2023-08-14 8:53 ` [patch V4 09/41] x86/cpu: Move cpu_core_id into topology info Thomas Gleixner
2023-10-13 9:38 ` [tip: x86/core] " tip-bot2 for Thomas Gleixner
2023-08-14 8:53 ` [patch V4 10/41] x86/cpu: Move cu_id " Thomas Gleixner
2023-10-13 9:38 ` [tip: x86/core] " tip-bot2 for Thomas Gleixner
2023-08-14 8:53 ` [patch V4 11/41] x86/cpu: Remove pointless evaluation of x86_coreid_bits Thomas Gleixner
2023-10-13 9:38 ` [tip: x86/core] " tip-bot2 for Thomas Gleixner
2023-08-14 8:53 ` [patch V4 12/41] x86/cpu: Move logical package and die IDs into topology info Thomas Gleixner
2023-10-13 9:38 ` [tip: x86/core] " tip-bot2 for Thomas Gleixner
2023-08-14 8:53 ` [patch V4 13/41] x86/cpu: Move cpu_l[l2]c_id " Thomas Gleixner
2023-10-13 9:38 ` [tip: x86/core] " tip-bot2 for Thomas Gleixner
2023-08-14 8:53 ` [patch V4 14/41] x86/apic: Use BAD_APICID consistently Thomas Gleixner
2023-10-13 9:38 ` [tip: x86/core] " tip-bot2 for Thomas Gleixner
2023-08-14 8:53 ` [patch V4 15/41] x86/apic: Use u32 for APIC IDs in global data Thomas Gleixner
2023-10-13 9:38 ` [tip: x86/core] " tip-bot2 for Thomas Gleixner
2023-08-14 8:53 ` [patch V4 16/41] x86/apic: Use u32 for check_apicid_used() Thomas Gleixner
2023-10-13 9:38 ` [tip: x86/core] " tip-bot2 for Thomas Gleixner
2023-08-14 8:54 ` [patch V4 17/41] x86/apic: Use u32 for cpu_present_to_apicid() Thomas Gleixner
2023-10-13 9:38 ` [tip: x86/core] " tip-bot2 for Thomas Gleixner
2023-08-14 8:54 ` [patch V4 18/41] x86/apic: Use u32 for phys_pkg_id() Thomas Gleixner
2023-10-13 9:38 ` [tip: x86/core] " tip-bot2 for Thomas Gleixner
2023-08-14 8:54 ` [patch V4 19/41] x86/apic: Use u32 for [gs]et_apic_id() Thomas Gleixner
2023-10-13 9:38 ` [tip: x86/core] " tip-bot2 for Thomas Gleixner
2023-08-14 8:54 ` [patch V4 20/41] x86/apic: Use u32 for wakeup_secondary_cpu[_64]() Thomas Gleixner
2023-10-13 9:38 ` [tip: x86/core] " tip-bot2 for Thomas Gleixner
2023-10-13 10:32 ` [tip: x86/core] x86/apic, x86/hyperv: Use u32 in hv_snp_boot_ap() too tip-bot2 for Ingo Molnar
2023-08-14 8:54 ` [patch V4 21/41] x86/cpu/topology: Cure the abuse of cpuinfo for persisting logical ids Thomas Gleixner
2023-10-13 9:38 ` [tip: x86/core] " tip-bot2 for Thomas Gleixner
2023-08-14 8:54 ` [patch V4 22/41] x86/cpu: Provide debug interface Thomas Gleixner
2023-10-13 9:38 ` [tip: x86/core] " tip-bot2 for Thomas Gleixner
2023-08-14 8:54 ` [patch V4 23/41] x86/cpu: Provide cpuid_read() et al Thomas Gleixner
2023-08-14 8:54 ` [patch V4 24/41] x86/cpu: Provide cpu_init/parse_topology() Thomas Gleixner
2023-08-28 6:07 ` K Prateek Nayak
2023-08-28 10:05 ` Thomas Gleixner
2023-08-28 14:03 ` Arjan van de Ven
2023-08-28 14:28 ` K Prateek Nayak
2023-08-28 14:34 ` Arjan van de Ven
2023-08-29 3:16 ` K Prateek Nayak
2023-09-15 11:54 ` Peter Zijlstra
2023-09-15 14:04 ` Arjan van de Ven
2023-09-19 3:54 ` K Prateek Nayak
2023-09-19 8:13 ` Thomas Gleixner
2023-09-20 3:23 ` K Prateek Nayak
2023-09-19 13:44 ` Arjan van de Ven
2023-09-20 3:21 ` K Prateek Nayak
2023-09-14 9:20 ` K Prateek Nayak [this message]
2023-09-15 11:46 ` Thomas Gleixner
2023-08-14 8:54 ` [patch V4 25/41] x86/cpu: Add legacy topology parser Thomas Gleixner
2023-08-14 8:54 ` [patch V4 26/41] x86/cpu: Use common topology code for Centaur and Zhaoxin Thomas Gleixner
2023-08-14 8:54 ` [patch V4 27/41] x86/cpu: Move __max_die_per_package to common.c Thomas Gleixner
2023-08-14 8:54 ` [patch V4 28/41] x86/cpu: Provide a sane leaf 0xb/0x1f parser Thomas Gleixner
2023-08-16 12:09 ` Zhang, Rui
2023-08-17 9:11 ` Thomas Gleixner
2023-08-14 8:54 ` [patch V4 29/41] x86/cpu: Use common topology code for Intel Thomas Gleixner
2023-08-14 8:54 ` [patch V4 30/41] x86/cpu/amd: Provide a separate accessor for Node ID Thomas Gleixner
2023-08-14 8:54 ` [patch V4 31/41] x86/cpu: Provide an AMD/HYGON specific topology parser Thomas Gleixner
2023-08-14 8:54 ` [patch V4 32/41] x86/smpboot: Teach it about topo.amd_node_id Thomas Gleixner
2023-08-14 8:54 ` [patch V4 33/41] x86/cpu: Use common topology code for AMD Thomas Gleixner
2023-08-14 8:54 ` [patch V4 34/41] x86/cpu: Use common topology code for HYGON Thomas Gleixner
2023-08-14 8:54 ` [patch V4 35/41] x86/mm/numa: Use core domain size on AMD Thomas Gleixner
2023-08-14 8:54 ` [patch V4 36/41] x86/cpu: Make topology_amd_node_id() use the actual node info Thomas Gleixner
2023-08-14 8:54 ` [patch V4 37/41] x86/cpu: Remove topology.c Thomas Gleixner
2023-08-14 8:54 ` [patch V4 38/41] x86/cpu: Remove x86_coreid_bits Thomas Gleixner
2023-08-14 8:54 ` [patch V4 39/41] x86/apic: Remove unused phys_pkg_id() callback Thomas Gleixner
2023-08-14 8:54 ` [patch V4 40/41] x86/xen/smp_pv: Remove cpudata fiddling Thomas Gleixner
2023-08-14 8:54 ` [patch V4 41/41] x86/apic/uv: Remove the private leaf 0xb parser Thomas Gleixner
2023-08-14 14:36 ` [patch V4 00/41] x86/cpu: Rework the topology evaluation Peter Zijlstra
2023-08-16 11:36 ` Zhang, Rui
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=011011ee-4f83-3545-4ca2-55bc0bef284a@amd.com \
--to=kprateek.nayak@amd.com \
--cc=andrew.cooper3@citrix.com \
--cc=arjan@linux.intel.com \
--cc=dimitri.sivanich@hpe.com \
--cc=gautham.shenoy@amd.com \
--cc=jgross@suse.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mikelley@microsoft.com \
--cc=puwen@hygon.cn \
--cc=qiuxu.zhuo@intel.com \
--cc=ray.huang@amd.com \
--cc=sohil.mehta@intel.com \
--cc=tglx@linutronix.de \
--cc=thomas.lendacky@amd.com \
--cc=wei.liu@kernel.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox