Hi Hanjun On 2017/8/9 22:08, Hanjun Guo wrote: > Hi Jeremy, > > On 8 August 2017 at 01:33, Jeremy Linton <jeremy.linton@xxxxxxx <mailto:jeremy.linton@xxxxxxx>> wrote: >> >> Hi, >> >> On 08/07/2017 05:20 AM, Hanjun Guo wrote: >>> >>> +Cc Xiongfeng (who is also working on the PPTT but focusing on >>> CPU topology) >>> >>> Hi Jeremy, >>> >>> On 2017/8/5 8:11, Jeremy Linton wrote: >>>> >>>> ACPI 6.2 adds the Processor Properties Topology Table (PPTT), which is >>>> used to describe the processor and cache topologies. Ideally it is >>>> used to extend/override information provided by the hardware, but >>>> right now ARM64 is entirely dependent on firmware provided tables. >>>> >>>> This patch parses the table for the cache topology only. Its quite >>>> trivial to add processor/cluster/???/socket level parsing as well, >>>> but that information isn't as useful as the already provided NUMA >>>> SRAT/SLIT information which provides relative distances. The one >>>> useful thing, is the number of physical sockets but due to the >>>> way arm64 considers "clusters" to be sockets, a larger discussion >>>> is required here. >>> >>> >>> I think we need the socket to represent the true topology of >>> the SoC, which means that considering clusters to be sockets is >>> wrong on ARM64 server platforms, a "socket" needs to be a memory >>> controller attached I think. >> I agree with you that clusters should not be considered as sockets. Cores in a cluster may share a L2 cache and should stay in a same local sched_domain for better performance. This is done in function cpu_coregroup_mask(), which use cpu_topology[cpu].core_sibling to build a sched_domain. The core_sibling information is also used in sysfs and considered as cores in a socket by "lscpu". I think we may need to add members 'physical_package_id' and 'cluster_sibling' in struct cpu_topology. So that cores in a cluster represented by 'core_sibling' are composed in a same local sched_domain, and cores in a package represented by 'cluster_sibling' are considered as a socket by 'lscpu'. Thanks, Xiongfeng Wang -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
