On Wed, Apr 05, 2023 at 03:12:38PM +0900, Akihiko Odaki wrote:
w we can merge
> Before this change, lscpu_cputype held topology information.
I do not understand why this is a problem. The topology (number of
threads, cores, etc.) is specific to the type of CPU, right?
I guess the sibling maps in kernel describes this.
> This
> design is incompatible with heterogenous configurations where there are
> several CPU types.
This design has been motivated by heterogenous systems :-)
Model name: Cortex-A53
Model: 4
Thread(s) per core: 1
Core(s) per socket: 4
Socket(s): 1
Model name: Cortex-A72
Model: 2
Thread(s) per core: 1
Core(s) per socket: 2
Socket(s): 1
How we can display "Core(s) per socket" if we will not differentiate
between the types?
> One problem is that logical IDs of e.g. clusters overlap across
> different CPU types. For example, consider a
> 1-socket/2-cluster/1-core/1-thread system. One of the clusters has
> "P-cores", and the other has "E-cores". P-cores and E-cores have
> different CPU types. Before this change,
> "lscpu -p=CPU,Core,Cluster,Socket" output something like the following
> for the system:
> 0,0,0,0
> 1,0,0,0
>
> Note that lscpu assigns the same core/cluster ID for the two CPUs
> although they are actually in different cores and clusters.
>
> To fix the inconsistency and ambiguity of such IDs, move the topology
> information from lscpu_cputype to lscpu_cxt. For the earlier example,
> the output will change as follows:
> 0,0,0,0
> 1,1,1,0
Then we need to fix _this output_, but not ignore cputypes for whole
lscpu.
> This also changes how the topology is described in the summary which
> lscpu prints when it is executed with no arguments. Before this change,
> the topology information was associated with CPU types, but the
> topology information is shown in a separate section now.
I don't like it. We had this output before lscpu rewrite and was pretty
confusing for users.
Karel
--
Karel Zak <kzak@xxxxxxxxxx>
http://karelzak.blogspot.com
