11-28-2018, 03:23 PM
System is an SoC, so getting GPU load is non-trivial since it's a bunch of direct-access "pins" and a kernel DRM bridge and stuff like that.
(I am sorry, I am intermediate level at this).
Then, the CPU cores are like this:
"ARM big.LITTLE"
It contains two "clusters".
First cluster contains 4 cores at low power, Cortex A53
Second cluster contains 2 cores with bigger power, Cortex A57
Both "sides" can't be active at the same time but RAM access is shared so tasks can be swapped between "sides" easily.
So you can literally never use all 6 cores at the same time.
It is supposed to be used in order to achieve better results in low power scenarios than just scaling CPU frequencies manually.
Linux big.LITTLE support is just entry-level now, and there is by default no big.LITTLE SMP scheduler but you can enable it if you recompile your kernel with it.
I haven't tried to use it myself yet as I am working on other areas.
And I'm not sure if any dtb work has to be done (see the command 'dtedit') in order to make it work, or work better.
(I am sorry, I am intermediate level at this).
Then, the CPU cores are like this:
"ARM big.LITTLE"
It contains two "clusters".
First cluster contains 4 cores at low power, Cortex A53
Second cluster contains 2 cores with bigger power, Cortex A57
Both "sides" can't be active at the same time but RAM access is shared so tasks can be swapped between "sides" easily.
So you can literally never use all 6 cores at the same time.
It is supposed to be used in order to achieve better results in low power scenarios than just scaling CPU frequencies manually.
Linux big.LITTLE support is just entry-level now, and there is by default no big.LITTLE SMP scheduler but you can enable it if you recompile your kernel with it.
I haven't tried to use it myself yet as I am working on other areas.
And I'm not sure if any dtb work has to be done (see the command 'dtedit') in order to make it work, or work better.