Hi Hanjun

On 2017/8/9 22:08, Hanjun Guo wrote:

Hi Jeremy,

On 8 August 2017 at 01:33, Jeremy Linton <jeremy.linton at arm.com <mailto:jeremy.linton@arm.com>> wrote:

quoted

Hi,

On 08/07/2017 05:20 AM, Hanjun Guo wrote:

quoted

+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:

quoted

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