mersenneforum.org

mersenneforum.org (https://www.mersenneforum.org/index.php)
-   Mlucas (https://www.mersenneforum.org/forumdisplay.php?f=118)
-   -   "sched_setaffinity: Invalid argument"? (https://www.mersenneforum.org/showthread.php?t=27480)

leonardyan96 2022-01-10 12:45

"sched_setaffinity: Invalid argument"?
 
I'm trying to run Mlucas on a Huawei Matepad pro 10.5" 2021, with Harmony OS 2.0.0(runs Android apps but said to be not Android), Snapdragon 870 and 8GiB RAM. I'm using all 8 cores and running v20.1.1 (02 Dec 2021).
After compiling, when running selftests I saw a lot of information lines as I quoted in the title. It repeats several times (roughly from 6 times to 12, as I see it) for each radix-set. For example:
[CODE]
Using complex FFT radices ..............
sched_setaffinity: Invalid argument
sched_setaffinity: Invalid argument
mers_mod_square: Init threadpool of 8 threads
sched_setaffinity: Invalid argument
sched_setaffinity: Invalid argument
sched_setaffinity: Invalid argument
sched_setaffinity: Invalid argument
sched_setaffinity: Invalid argument
sched_setaffinity: Invalid argument
sched_setaffinity: Invalid argument
sched_setaffinity: Invalid argument
sched_setaffinity: Invalid argument
Using 8 threads in carry step
sched_setaffinity: Invalid argument
[/CODE]
After that it runs actual FFT and prints the results. For now the selftest hasn't completed but almost all radix-sets was successful. However I don't remember seeing these lines when testing with another Android device 2 months before (possibly using an earlier patch version of Mlucas). Also, actual pm1 running on that Android device doesn't produce such lines.

So does this mean anything usual or terrible?

leonardyan96 2022-01-10 12:53

These lines also appear when running single-threaded (omitting -cpu flags).

leonardyan96 2022-01-10 14:17

After some search I learned this is a function provided by the Linux environment. I tried the following command, it successfully finished and that message still appeared twice.
[CODE]./Mlucas -fft 192 -iters 100 -radset 0 -cpu 1[/CODE]

leonardyan96 2022-01-10 14:35

According to what I found with some more tests, when I specify any cpu cores other than 2 and 3 the error message will appear. When -cpu 2, -cpu 3 or -cpu 2:3 the screen output gets clean. It might be something weird with the OS or SoC, but doesn't stop the FFT from being correctly finished.

chris2be8 2022-01-10 16:34

What is in /proc/cpuinfo ? It sounds as if Linux thinks it only has CPUs 2 and 3.

ewmayer 2022-01-10 21:36

[QUOTE=chris2be8;597576]What is in /proc/cpuinfo ? It sounds as if Linux thinks it only has CPUs 2 and 3.[/QUOTE]

Echoed - some OSes do weird things with respect to physical and/or logical core numbering. An attempt to set a thread's affinity to a non-existent core (based on the OS' core numbering scheme, as captured in /proc/cpuinfo) will simply leave any thread affinity management to the OS, but obviously one would prefer to not get warning messages in one's runs.

leonardyan96 2022-01-10 23:27

[QUOTE=chris2be8;597576]What is in /proc/cpuinfo ? It sounds as if Linux thinks it only has CPUs 2 and 3.[/QUOTE]

IMO if there's only 2 cores shown in /proc/cpuinfo, Mlucas will report 2 cores too, instead of 8.

I'll check this later.

leonardyan96 2022-01-11 01:22

Selftest just finished. In mlucas.cfg the timings look bad, from 2000 to 7000 ms/iter. Seems that it failed to utilize all the cores.

leonardyan96 2022-01-11 01:33

[QUOTE=chris2be8;597576]What is in /proc/cpuinfo ? It sounds as if Linux thinks it only has CPUs 2 and 3.[/QUOTE]

CPU numbers in it looks normal, from 0 to 7.
I tried taskset yet doesn't work.

I'm going to give up, since I'm not able to root it or flash a custom ROM, and I'm not planning to run Mlucas on it for a long term. It's purchased only a few months ago.

leonardyan96 2022-01-11 02:46

Just did another test on my daily phone with Snapdragon 835. It has 8 cores, among which little cores are 0-3 and big cores are 4-7.
The little cores can all be safely specified without any warning. However those big cores look tricky. Sometimes it's 4 and 5 which work, sometimes 4 & 6, and sometimes 5 & 7. It seems unstable.
According to the timing, when I specify only 1 core and it warns "Invalid argument", the program seems to fall back to only one small core(cpu 0?). This is the slowest case.
I'm not sure if root or custom ROM works. Qualcomm chips are really a pain in the ass... :surrender

ewmayer 2022-01-11 19:07

[QUOTE=leonardyan96;597629]Just did another test on my daily phone with Snapdragon 835. It has 8 cores, among which little cores are 0-3 and big cores are 4-7.
The little cores can all be safely specified without any warning. However those big cores look tricky. Sometimes it's 4 and 5 which work, sometimes 4 & 6, and sometimes 5 & 7. It seems unstable.
According to the timing, when I specify only 1 core and it warns "Invalid argument", the program seems to fall back to only one small core(cpu 0?). This is the slowest case.
I'm not sure if root or custom ROM works. Qualcomm chips are really a pain in the ass... :surrender[/QUOTE]

Have you ever been able to run using '-cpu 0:7' without the invalid-argument warnings, or is 6 cores the maximum that has (sometimes) worked? It sounds like the OS is doing some kind of dynamic core binding/unbinding. Note that the pthread affinity-setting is formally a *hint* to the OS, whether it gets respected or not depends on the OS and the particuar device in question. Apple M1 is another such 4-big|4-little 8-core hybrid, but there cores 0-7 are always available. I suggest you try just using -cpu 0:3 and run self-tests (preferably with the phone mostly idle at the time and in some decent airflow), in hopes the OS will remap the process to mostly use the performance cores.

leonardyan96 2022-01-11 23:49

[QUOTE=ewmayer;597673]Have you ever been able to run using '-cpu 0:7' without the invalid-argument warnings, or is 6 cores the maximum that has (sometimes) worked? It sounds like the OS is doing some kind of dynamic core binding/unbinding. Note that the pthread affinity-setting is formally a *hint* to the OS, whether it gets respected or not depends on the OS and the particuar device in question. Apple M1 is another such 4-big|4-little 8-core hybrid, but there cores 0-7 are always available. I suggest you try just using -cpu 0:3 and run self-tests (preferably with the phone mostly idle at the time and in some decent airflow), in hopes the OS will remap the process to mostly use the performance cores.[/QUOTE]

-cpu 0:7 will also cause this warning.

leonardyan96 2022-01-11 23:54

[QUOTE=ewmayer;597673]Have you ever been able to run using '-cpu 0:7' without the invalid-argument warnings, or is 6 cores the maximum that has (sometimes) worked? It sounds like the OS is doing some kind of dynamic core binding/unbinding. Note that the pthread affinity-setting is formally a *hint* to the OS, whether it gets respected or not depends on the OS and the particuar device in question. Apple M1 is another such 4-big|4-little 8-core hybrid, but there cores 0-7 are always available. I suggest you try just using -cpu 0:3 and run self-tests (preferably with the phone mostly idle at the time and in some decent airflow), in hopes the OS will remap the process to mostly use the performance cores.[/QUOTE]

On that phone I mentioned before, which use a MediaTek SoC, all 8 cores are always avaliable. I have never seen such warning in ordinary pm1 runs.

leonardyan96 2022-01-14 03:53

From manpage 2 sched_setaffinity:
[QUOTE]EINVAL

The affinity bit mask mask contains no processors that are currently physically on the system and permitted to the process according to any restrictions that may be imposed by the "cpuset" mechanism described in cpuset(7).[/QUOTE]

I guess, when I specify '-cpu 0:7', Mlucas creates 8 threads, then uses sched_setaffinity to set affinity of only one core for each thread. When a thread hits an inavailable core, out comes the "Invalid argument" error.

Since all 8 cores present in /proc/cpuinfo with typical numbering 0-7, I guess it's the cpuset mechanism, as defined in /dev/cpuset, who stops me from using some cores. However I don't have permission to ls /dev, maybe requires rooting. I wonder if Harmony OS imposes more restriction than normal Android.

leonardyan96 2022-01-14 09:24

/dev/cpuset, the pid of Mlucas as well as CPU restriction info in /proc/<mlucas pid>/status can all be obtained via ADB. I'm doing some more investigation though doesn't seem very hopeful:confused:

I might be learning something about Linux process scheduling...

leonardyan96 2022-01-23 12:22

EUREKA!
 
The core control mechanism, developed by Qualcomm, is the most possible reason of not being able to use all cores.
I checked /sys/devices/system/cpu/core_ctl_isolated via ADB, which seems to contain numbers of those cores not available for use. For the first time it reads "4,7". When I checked it again a moment later, it was changed into "4,6". Later it's empty, and I can specify "-cpu 0:7" without any setaffinity errors. Now it reads "5,6", "-cpu 0:4,7" works well while "-cpu 0:7" causes error this time.
If it can be rooted I might be able to solve the problem by changing the parameters of core_ctl.

ewmayer 2022-01-23 18:41

Thanks for digging into this - sounds like the OS is dynamically adding and removing cores from the set available for user processes.

When you start a job with '-cpu 0:7' and it starts without the sched_setaffinity errors, if you monitor the program using 'top' for a few minutes, what % CPU usage does it show, and does it vary significantly? What about when the thus-started job does emit the sched_setaffinity error messages - does the resulting CPU usage look different in 'top'?

Again, in either case it's ultimately up to the OS to manage thread affinity - if you end up with similar runtime CPU utilization in either case (with and w/o error messages), perhaps I should just milden the messaging to a warning to the effect of "leaving thread affinity up to OS".

leonardyan96 2022-01-24 12:25

[QUOTE=ewmayer;598660]Thanks for digging into this - sounds like the OS is dynamically adding and removing cores from the set available for user processes.

When you start a job with '-cpu 0:7' and it starts without the sched_setaffinity errors, if you monitor the program using 'top' for a few minutes, what % CPU usage does it show, and does it vary significantly? What about when the thus-started job does emit the sched_setaffinity error messages - does the resulting CPU usage look different in 'top'?

Again, in either case it's ultimately up to the OS to manage thread affinity - if you end up with similar runtime CPU utilization in either case (with and w/o error messages), perhaps I should just milden the messaging to a warning to the effect of "leaving thread affinity up to OS".[/QUOTE]
You get it right. core_ctl is a kernel module which dynamically isolates/unisolates cores according to CPU load. Isolated cored can't be used by progresses, so it won't be woke up, saving energy. My phone's 835 has 8 cores divided into 2 clusters. One cluster contains 4 small cores, the other one contains 4 big cores. The small cluster is always fully unisolated, while the big one has 2 isolated cores nearly all the time, unless I launch some resource-demanding apps, which itself affects Mlucas' performance. At least today I have never managed to run mlucas with "-cpu 0:7" without setaffinity error.
core_ctl has an interface called core_ctl_set_boost which unisolates all cores, but it can only be used by other kernel modules, meaning I can't unisolate all cores manually on an not-rooted device.
I ran two sets of tests today, both with 2 cores isolated. Due to background services from other apps the timing may vary a bit between each tests, but not very much.
[CODE]./Mlucas -fft 5632 -iters 1000 -radset 0 -cpu 0:7[/CODE]
It showed some errors. Mlucas used ~600% of cpu, and the test cost about 1 min 40 sec.
[CODE]./Mlucas -fft 5632 -iters 1000 -radset 0 -cpu 0:5[/CODE]
This time I avoided 2 isolated cores and there was no error. However, radix 0/2 is not exactly divisible by NTHREADS=6 and carry step only uses 4 threads. Mlucas used ~450% of cpu, and the test cost about 2 min 30 sec.
Apparently, even if affected by isolated cores, specifying all cores still yields better performance.
What I worry about is, if a thread is set onto an isolated core, it might have to share another core with another thread, hurting performance. Because I'm currently using this phone, currently I don't want to try rooting it, so I'm not able to test the case of using all 8 cores without hitting isolated cores.

chris2be8 2022-01-24 16:25

Are there any user controls for core_ctl? Eg can it be told not to isolate any cores if the phone is plugged into a charger? Energy saving isn't needed then.

ewmayer 2022-01-24 22:34

I did a preliminary online search for 'core_ctl', found very little material. May be wrong, but perhaps this power-management mechanism is intended to be accessible by the OS only. Your timings indicate that even with the OS dynamically isolating a few cores, aside from the init-phase "unable to set thread affinity" error messages, the process is running fine. That makes sense because any such power-management would need to be able to bounce threads between cores without stalling their execution. Note that Mlucas-used threadpool schema is designed for asynchronous execution, i.e. even if some threads briefly stall or run more slowly than others, that simply means that the slower threads end up doing fewer work units during the given iteration; the only constraint being that all threads must complete their final work unit by way of resynchronization, before execution can continue to the next of the 2 main parallel-executed phases of each iteration.

For example, your runs at 5.5M FFT and radix set 0 have leading radix R = 352. For technical FFT-implementation reasons not important here, that results in R/2 = 176 independent work units. For '-cpu 0:7' those get assigned to a pool of 8 threads, each thread completes its current WU then grabs the next-available one, as long as there are WUs left which need to get done. In the idealized case of all threads running in precise lockstep, using 6 threads, you'd have each doing floor(176/6) = 29 WUs, leaving 2 WUs, so those would need 2 threads, leaving 4 idle threads for the final pass, for a performance hit of perhaps 3% over the ideal case. In your case, even with 8 threads, the OS dynamically isolating and freeing-up cores results in more or less the same kind of thing - as long as there's a decent amount of work to divvy up amongst the cores & threads, it's OK.

Again for technical reasons the parallel carry-step needs a power-of-2 thread count, so when you run with e.g. '-cpu 0:5', the carry step uses just 4 threads - that's why it's generally preferable to stick to power-of-2 thread counts, and "fill the CPU up" with those. Say on a 6-core CPU you'd have three 2-thread instances or one 4-thread and one 2-thread. Your hardware is a little special in that regard, but it seems best to optimistically assume all 8 cores will be available much of the time.

Just by way of 1 more throughput reference, what timing for the same 1000-iter self-test @5.5M FFT do you get using '-cpu 0:3'? As long as 8-threaded is running faster than any lower threadcount, just go with that, and I'll milden the scary-sounding affinity-error messages to warnings in the next release.

leonardyan96 2022-01-25 00:18

[QUOTE=chris2be8;598712]Are there any user controls for core_ctl? Eg can it be told not to isolate any cores if the phone is plugged into a charger? Energy saving isn't needed then.[/QUOTE]

At least the stock ROM of my phone doesn't have this. Smartphone manufacturers in China tend to put some "gaming mode" or "performance mode" in their products, but I'm not sure if they change the behaviour of core_ctl, since mine is from a little-known foreign brand.

Also, when I check the status of core_ctl via ADB it has already been charging, obviously the core isolation is not disabled in this situation.

leonardyan96 2022-01-25 02:00

[QUOTE=ewmayer;598741]I did a preliminary online search for 'core_ctl', found very little material. May be wrong, but perhaps this power-management mechanism is intended to be accessible by the OS only. Your timings indicate that even with the OS dynamically isolating a few cores, aside from the init-phase "unable to set thread affinity" error messages, the process is running fine. That makes sense because any such power-management would need to be able to bounce threads between cores without stalling their execution. Note that Mlucas-used threadpool schema is designed for asynchronous execution, i.e. even if some threads briefly stall or run more slowly than others, that simply means that the slower threads end up doing fewer work units during the given iteration; the only constraint being that all threads must complete their final work unit by way of resynchronization, before execution can continue to the next of the 2 main parallel-executed phases of each iteration.

For example, your runs at 5.5M FFT and radix set 0 have leading radix R = 352. For technical FFT-implementation reasons not important here, that results in R/2 = 176 independent work units. For '-cpu 0:7' those get assigned to a pool of 8 threads, each thread completes its current WU then grabs the next-available one, as long as there are WUs left which need to get done. In the idealized case of all threads running in precise lockstep, using 6 threads, you'd have each doing floor(176/6) = 29 WUs, leaving 2 WUs, so those would need 2 threads, leaving 4 idle threads for the final pass, for a performance hit of perhaps 3% over the ideal case. In your case, even with 8 threads, the OS dynamically isolating and freeing-up cores results in more or less the same kind of thing - as long as there's a decent amount of work to divvy up amongst the cores & threads, it's OK.

Again for technical reasons the parallel carry-step needs a power-of-2 thread count, so when you run with e.g. '-cpu 0:5', the carry step uses just 4 threads - that's why it's generally preferable to stick to power-of-2 thread counts, and "fill the CPU up" with those. Say on a 6-core CPU you'd have three 2-thread instances or one 4-thread and one 2-thread. Your hardware is a little special in that regard, but it seems best to optimistically assume all 8 cores will be available much of the time.

Just by way of 1 more throughput reference, what timing for the same 1000-iter self-test @5.5M FFT do you get using '-cpu 0:3'? As long as 8-threaded is running faster than any lower threadcount, just go with that, and I'll milden the scary-sounding affinity-error messages to warnings in the next release.[/QUOTE]

With other parameters remained the same, when using 4 small cores it uses ~370% of CPU and about 3 min 42 sec, while it's ~390% of CPU and about 1 min 31 sec when 4 big cores(with setaffinity errors). It's strange that the timing of using all 8 cores is no better than 4 big cores only:confused:

I also tried my previous phone with a low-end octacore MediaTek SoC, not affected by core isolation. With all 8 cores used it takes 750% of CPU and about 3 minutes. Even with some cores isolated the Sanpdragon 835 is still far more powerful:bounce:

The conclusion is clear: using all cores (with multiple instances when necessary) should always be the best choice. If anyone has a rooted device, unisolating all cores might still help with the performance, but for now I'm not able to verify this.

LaurV 2022-01-26 09:34

I am using an app to control cpu/gpu frequencies and to show temperatures in a 10-core CPU on ubuntu. It is also called "core-ctl-something" (note, I am not at home right now to check, and generally I am a linux noob, only using it in some mining rig because mining is faster, R-vii windows drivers suck) - anyhow, maybe this info helps somehow, or give somebody some idea: on the chart which shows the cores' temps, the cores are numbered 0,1,2,3,4,8,9,10,11,12. Don't ask me why...
(edit, it looks indeed like a crippled 16-cores CPU, or maybe it is like that, internally).

ewmayer 2022-01-26 19:07

1 Attachment(s)
[QUOTE=LaurV;598822]I am using an app to control cpu/gpu frequencies and to show temperatures in a 10-core CPU on ubuntu. It is also called "core-ctl-something" (note, I am not at home right now to check, and generally I am a linux noob, only using it in some mining rig because mining is faster, R-vii windows drivers suck) - anyhow, maybe this info helps somehow, or give somebody some idea: on the chart which shows the cores' temps, the cores are numbered 0,1,2,3,4,8,9,10,11,12. Don't ask me why...
(edit, it looks indeed like a crippled 16-cores CPU, or maybe it is like that, internally).[/QUOTE]

The OP's case is different in that his /proc/cpuinfo shows core numbers 0-7, as expected. But yes, especially Intel sometimes uses utterly bizarre internal numbering - I've integrated the hwloc package into the current Mlucas dev-branch to automatically handle such weirdness. The command-line version of hwloc is, oddly, named 'lstopo' - attached is its visual rendering of the topology for another Intel chip, a 61c244t Knights Corner copro CPU - in the rendering, the grey-shaded "Core L#--" entries are physical cores, "P#--" are the attached logical cores in Intel's numbering (the one which is used to generate the /proc/cpuinfo data), and "PU L#--" are the hwloc-reindexed logical cores. Check out Intel's numbering of the 4 logical cores mapped to physical core 0, for instance:

leonardyan96 2022-06-15 11:13

I just found, for a Snapdragon 835 the best way is using 2 instances. One for big cores and one for small cores. When using -cpu 0:3 or 4:7 the selftest in the middle range can be finished within less than 30 min, but with one instance using all 8 cores, it takes several hours! I'm not sure whether I ignored anything or not.

ewmayer 2022-06-16 21:58

[QUOTE=leonardyan96;607893]I just found, for a Snapdragon 835 the best way is using 2 instances. One for big cores and one for small cores. When using -cpu 0:3 or 4:7 the selftest in the middle range can be finished within less than 30 min, but with one instance using all 8 cores, it takes several hours! I'm not sure whether I ignored anything or not.[/QUOTE]

Interesting, thanks. Do you now have 2 production-run instances running on the respective 4-core subsets, and if so, what are the respective exponents/runtimes? On Galaxy S7 with its hybrid quadcore (2 big, 2 little) I get quite good performance from running 1 instance on all 4 cores, so the big/little disparity must be significantly greater on 835. What are the basic (e.g. as per /proc/cpuinfo) data for the 2 different types of cores on the 835?

I see the 835 first appeared in Galaxy S8, which is by now old enough that still-functioning for-parts one should be gettable reasonably cheaply. Here the roadmap for the [url=https://en.wikipedia.org/wiki/Qualcomm_Snapdragon]processor series[/url], from Wikipedia:
[quote]In early 2016, Qualcomm launched the Snapdragon 820, an ARM 64-bit quad-core processor using in-house designed Kryo cores. Qualcomm launched an updated Snapdragon 821 later in the year with higher clock speeds and slightly better performance. The Snapdragon 820 family uses Samsung's 14-nanometer FinFET process. Qualcomm also released the Qualcomm Snapdragon Neural Processing Engine SDK which was the first AI acceleration on smartphones.[62]

Qualcomm announced the octa-core Snapdragon 835 SoC on 17 November 2016. Released the following year, it uses Kryo 280 cores and is built using Samsung's 10-nanometer FinFET process. At initial launch, due to Samsung's role in manufacturing the chip, its mobile division also acquired the initial inventory of the chip. That means that no other phone maker was able to manufacture products containing the Snapdragon 835 until Samsung released its flagship device of the year, the Galaxy S8.[63]

At Computex 2017 in May, Qualcomm and Microsoft announced plans to launch Snapdragon-based laptops running Windows 10. Qualcomm partnered with HP, Lenovo, and Asus to release slim portables and 2-in-1 devices powered by the Snapdragon 835.[64]

In December 2017, Qualcomm announced the octa-core Snapdragon 845. It uses the same 10-nanometer manufacturing process as the earlier Snapdragon 835 but introduced a new processor architecture, Kryo 385,[65] designed for better battery life, photography, and for use with artificial intelligence apps.[66][65]

In early 2018, Qualcomm introduced the 7 series, which sits between the 6 and 8 series in terms of pricing and performance. The 700 launched with octa-core models Snapdragon 710 and 712, using the Kryo 360 processor architecture, and built on a 10-nanometer manufacturing process.[67][68][69]

In 2019, Qualcomm released new variants of its mobile processors, with the Snapdragon 855 replacing the 845. The Snapdragon 855 competes against other high end system-on-chip solutions like the Apple A12, and Kirin 980. The Snapdragon 855 features Kryo 485 cores, built on TSMC's 7-nanometer process.[70] The Snapdragon 730 and 730G replaced the 710 and 712. The newer 730 and 730G feature Kryo 460 cores, built on Samsung's 8-nanometer process.[71]

In December 2019, Qualcomm announced the Snapdragon 865 and Snapdragon 765, which succeeded the Snapdragon 855/855+ and Snapdragon 730/730G respectively. The Snapdragon 765 has integrated 5G, while the Snapdragon 865 is assisted by a separate Qualcomm X55 5G modem. Despite lacking integrated 5G, the Snapdragon 865 is incompatible with 4G phones.[72][73]

In May 2020, Qualcomm announced the new Snapdragon 768G 5G processor, an upgraded version of the 765G processor. The main difference between the 765G and 768G is that the 768G will offer 15 percent increase in performance and higher clock speed on the CPU, up to 2.8 GHz from 2.4 GHz.[74]

In September 2020, Qualcomm unveiled the Snapdragon 750G processor, the latest addition to the 7-series, designed to bring 5G support for low-latency mobile gaming.[75]

In December 2020, Qualcomm unveiled the Snapdragon 888. The major differences compared to the 865/+ is a new core, designed by ARM, the ARM Cortex X1, support for LPDDR5-6400 and a built in 5G modem, meaning the X55 Modem is not required. The 888 is based on Samsung 5nm, with a TDP of 5 watts, but this can be altered by the manufacturer.[76][/quote]

leonardyan96 2022-07-20 14:00

All of them are p-1 works in worktodo.ini, not selftests
Running only 1 instance for 4 big cores: M115762417 S1 140ms/iter
Running only 1 instance for 4 small cores: M115762483 S1 230ms/iter
If running 2 instances for 2 core groups the timings are quite close to the figures above.
Running 1 instance for all 8 cores: M115762417 S1 115ms/iter

leonardyan96 2022-07-20 14:07

[CODE]Cell:/ $ cat /proc/cpuinfo
Processor : AArch64 Processor rev 4 (aarch64)
processor : 0
BogoMIPS : 38.40
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32
CPU implementer : 0x51
CPU architecture: 8
CPU variant : 0xa
CPU part : 0x801
CPU revision : 4

processor : 1
BogoMIPS : 38.40
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32
CPU implementer : 0x51
CPU architecture: 8
CPU variant : 0xa
CPU part : 0x801
CPU revision : 4

processor : 2
BogoMIPS : 38.40
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32
CPU implementer : 0x51
CPU architecture: 8
CPU variant : 0xa
CPU part : 0x801
CPU revision : 4

processor : 3
BogoMIPS : 38.40
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32
CPU implementer : 0x51
CPU architecture: 8
CPU variant : 0xa
CPU part : 0x801
CPU revision : 4

processor : 4
BogoMIPS : 38.40
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32
CPU implementer : 0x51
CPU architecture: 8
CPU variant : 0xa
CPU part : 0x800
CPU revision : 1

processor : 5
BogoMIPS : 38.40
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32
CPU implementer : 0x51
CPU architecture: 8
CPU variant : 0xa
CPU part : 0x800
CPU revision : 1

processor : 6
BogoMIPS : 38.40
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32
CPU implementer : 0x51
CPU architecture: 8
CPU variant : 0xa
CPU part : 0x800
CPU revision : 1

processor : 7
BogoMIPS : 38.40
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32
CPU implementer : 0x51
CPU architecture: 8
CPU variant : 0xa
CPU part : 0x800
CPU revision : 1

Hardware : Qualcomm Technologies, Inc MSM8998[/CODE]

leonardyan96 2022-07-20 14:24

According to /sys/devices/system/cpu/cpufreq, the small cores top at 1.90Ghz and the big cores top at 2.46GHz.


All times are UTC. The time now is 02:37.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2022, Jelsoft Enterprises Ltd.