From: Akihiko Odaki <akihiko.odaki@daynix.com>
To: Karel Zak <kzak@redhat.com>
Cc: util-linux@vger.kernel.org
Subject: Re: [PATCH] lscpu: Decouple cputype and topology
Date: Wed, 26 Apr 2023 03:29:47 +0900 [thread overview]
Message-ID: <5092a67c-0b86-134a-df77-433a6db10900@daynix.com> (raw)
In-Reply-To: <4674295f-374b-2610-66b3-c2d2828a76ff@daynix.com>
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
>>
prev parent reply other threads:[~2023-04-25 18:29 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-05 6:12 [PATCH] lscpu: Decouple cputype and topology Akihiko Odaki
2023-04-05 10:43 ` Karel Zak
2023-04-05 15:32 ` Akihiko Odaki
2023-04-25 18:29 ` Akihiko Odaki [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5092a67c-0b86-134a-df77-433a6db10900@daynix.com \
--to=akihiko.odaki@daynix.com \
--cc=kzak@redhat.com \
--cc=util-linux@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).