-
-
Notifications
You must be signed in to change notification settings - Fork 441
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Suggestion: differentiate between big and little cores #879
Comments
Totally. Can we have some |
Should be a change in our internal CPU structure so this can be supported on all OS. |
It should be fine not to show it on OSs that don't make it ridiculously
easy to get the information. There are also parts that have more than two
types of core (Mediatek's newest SoC has 3). I'll dig into a couple of
those and check what I can find.
…On Wed, Nov 24, 2021 at 3:20 PM BenBE ***@***.***> wrote:
Should be a change in our internal CPU structure so this can be supported
on all OS.
Information to query these information on other OS than Linux are
appreciated.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#879 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABNDCSXDDKCE372VJGTVMTUNT7CHANCNFSM5IVWI46Q>
.
--
Ricardo Bánffy
http://about.me/rbanffy
|
In this case even writing the core type names may be an option if no/little processing is needed to get to those identifiers … |
Perhaps it would also make sense to add information about hyper-threading here, so where a core is the "primary" one or a hyper-threaded one. Should be possible to get the required information by grouping by |
Not sure there is a difference between a primary and an SMT core when SMT is enabled - they just behaves as another core that shares the same resources (and have more resources available as you turn off secondary threads - x86's (original Xeon Phi excepted) have 2 threads, but POWER and SPARC can have up to 8 threads per core). One way to present it would be to group SMT cores (maybe with line drawing characters such as ┌, ├, and └) that belong to a single core to indicate with how many SMT cores the physical core is being shared with (but that would create some complications with screen layouts). |
Of course there is no priority between hyper-threaded cores, both (or all) work the same. I just would like to see what cores belong to each other when it comes to hyper-threading. |
This is what
Nothing to distinguish between However looking at output of
|
Nice! And we can see the P and E cores from the MAXMHZ column in lscpu (which seems reasonable) |
Yes, the frequency is different, but I am not sure this is something one can rely on. Chances are that different core types have the same max frequency. |
I was looking into the same problem. The kernel exposes a
The only documentation I see on this says:
Unsure if this is reliable enough to use to group processors into big/little EDIT: my bad, there's a spec on this. Looking for the interpretation of these numbers here... |
Sounds like a plausible plan. Wondering how it could be represented
visually.
…On Sun, Oct 9, 2022 at 8:53 PM Karthik Karanth ***@***.***> wrote:
I was looking into the same problem. The kernel exposes a highest_perf
number:
$ head -n +1 /sys/devices/system/cpu/cpu*/acpi_cppc/highest_perf
==> /sys/devices/system/cpu/cpu0/acpi_cppc/highest_perf <==
61
==> /sys/devices/system/cpu/cpu1/acpi_cppc/highest_perf <==
61
==> /sys/devices/system/cpu/cpu2/acpi_cppc/highest_perf <==
61
==> /sys/devices/system/cpu/cpu3/acpi_cppc/highest_perf <==
61
==> /sys/devices/system/cpu/cpu4/acpi_cppc/highest_perf <==
61
==> /sys/devices/system/cpu/cpu5/acpi_cppc/highest_perf <==
61
==> /sys/devices/system/cpu/cpu6/acpi_cppc/highest_perf <==
61
==> /sys/devices/system/cpu/cpu7/acpi_cppc/highest_perf <==
61
==> /sys/devices/system/cpu/cpu8/acpi_cppc/highest_perf <==
63
==> /sys/devices/system/cpu/cpu9/acpi_cppc/highest_perf <==
63
==> /sys/devices/system/cpu/cpu10/acpi_cppc/highest_perf <==
63
==> /sys/devices/system/cpu/cpu11/acpi_cppc/highest_perf <==
63
==> /sys/devices/system/cpu/cpu12/acpi_cppc/highest_perf <==
61
==> /sys/devices/system/cpu/cpu13/acpi_cppc/highest_perf <==
61
==> /sys/devices/system/cpu/cpu14/acpi_cppc/highest_perf <==
61
==> /sys/devices/system/cpu/cpu15/acpi_cppc/highest_perf <==
61
==> /sys/devices/system/cpu/cpu16/acpi_cppc/highest_perf <==
36
==> /sys/devices/system/cpu/cpu17/acpi_cppc/highest_perf <==
36
==> /sys/devices/system/cpu/cpu18/acpi_cppc/highest_perf <==
36
==> /sys/devices/system/cpu/cpu19/acpi_cppc/highest_perf <==
36
The only documentation I see on this
<https://www.kernel.org/doc/html/v5.2/admin-guide/acpi/cppc_sysfs.html>
says:
highest_perf : Highest performance of this processor (abstract scale).
Unsure if this is reliable enough to use to group processors
—
Reply to this email directly, view it on GitHub
<#879 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABNDCVGB65XFXLDPFNYBADWCMPE3ANCNFSM5IVWI46Q>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
--
Ricardo Bánffy
http://about.me/rbanffy
|
What about marking the small cores with shadow'd numbers? The alternative of marking the big cores in bold is suboptimal as it causes a visual change even for users with hardware that doesn't distinguish those cores. |
The difference between E and P cores is only one type of grouping cores together. What do you think about a general grouping of cores in htop to visualize differences. For example HT (which core relates to another physical core), NUMA groups, P/E cores and i guess more different groups are coming and then only a shadow'd number is not enough anymore. |
Mesa introduced support for detecting this: Can we reuse any of this? |
This tries to read from |
Wouldn't it be better to have a new kind of CPU meter with such grouping enabled? Maybe something akin to |
The more important part for now is how to get the required information from system... |
Maybe we could get this done for ARM first, for which your last reply does work (checking the |
Not sure... Still wondering if there is a generic solution that works for all architectures. |
Main issue for this is still that |
Closes htop-dev#806. Closes htop-dev#1048. Closes htop-dev#1176. Closes htop-dev#1335. Addresses htop-dev#879 (on Linux).
Closes htop-dev#806. Closes htop-dev#1048. Closes htop-dev#1176. Closes htop-dev#1335. Addresses htop-dev#879 (on Linux).
Oh, there is intel-lpmd, the Intel Low Power Mode Daemon. Perhaps we can steal some code and/or ideas there? |
Just found libcpuid, which reports purpose of |
Another tool worth looking at is |
Closes htop-dev#806. Closes htop-dev#1048. Closes htop-dev#1176. Closes htop-dev#1335. Addresses htop-dev#879 (on Linux).
Various ARM platforms have been doing it with big.LITTLE and DinamiQ for some time, with different cores, and Apple's M1 and Intel's Alder Lake made it into the mainstream now. It'd be useful to see which CPUs are of which kind, perhaps showing them with their numbers in bold if they are "Performance" cores and normal if they are "Efficient" ones.
The text was updated successfully, but these errors were encountered: