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