On 2023/04/06 0:32, Akihiko Odaki wrote:
On 2023/04/05 19:43, Karel Zak wrote:
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?
Well, I think the output is confusing in the same way the output of
""lscpu -p=CPU,Core,Cluster,Socket" is. It says "socket(s): 1" for both
of Cortex-A53 and Cortex-A72, but they are actually in the same socket.
If there is a separate topology section there will be no such confusion.
Regards,
Akihiko Odaki
Hi,
Can you have a look at this again? My opinion here is we cannot reliably
tell "core(s) per socket" or "socket(s)" which belongs to a CPU type
because we do not know what separates CPU types.
For example, if you have different CPUs on different sockets, it makes
sense to provide "core(s) per socket" and "socket(s)" values for each
CPU type. However, if a CPU on a socket has a few clusters with
different CPU types, they do not make sense. Of course we can have
"core(s) per cluster" and "cluster(s)" values for each CPU type in such
a case, but determining what distinguishes CPU types (cluster or socket,
or possibly even something else?) introduces more complexity.
However I'm recently wondering if completely removing topology
information from CPU types is not ideal either. Perhaps each CPU type
can have a new value, "CPU(s) list" as the NUMA section does. It will
not tell about topology as much as the current topology information tied
with CPU types does, but you need something like "lscpu
-p=CPU,Core,Cluster,Socket" for complete topological information even
now. A CPU list is not confusing at least and concise.
It also allows to associate the CPU type information in the summary with
the output of "lscpu -p=CPU,Core,Cluster,Socket". This information is
also useful to run taskset to bind a process to a specific CPU type and
e.g. to compare performance of big and LITTLE cores.
Regards,
Akihiko Odaki
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
