You may want to learn more deeply about the architecture from Rockchip.
Perhaps there will be some fortune, and you might find the missing piece.
http://opensource.rock-chips.com/wiki_Main_Page
In the SDK,
http://opensource.rock-chips.com/wiki_Linux_SDK
there are schematics and TRMs and such.
I have low programming skill, low engineering skill, no degrees, and I'm self-taught, but I'll dump out everything else that I can think of:
- I understand there is a big.LITTLE SMP scheduler module available in the kernel Kconfig, but I've never used it, because I can't personally use kernels beyond 4.4.138, and 138 doesn't have that scheduler yet. It DOES compile successfully though - maybe give that a shot once to see if it behaves differently. (But then other parts of the rk3399 won't be working right, such as HDMI audio.)
- I don't know if that scheduler will help what you're doing whatsoever.
- My assumption is that any code must know about, and actively choose to flip over to big cluster. Generally, since Linux tasks are small and numerous, 4 slower cores generally get more "done" than a faster set of 2 cores, so the 4 cores are the sensible default. Also, the big cluster requires more power to run, and being a SBC, you can see why they chose power savings by default, etc.
- There are several pieces that go along with big.LITTLE that are also not quite working yet in Linux kernels, and there's various levels of "working" depending on exactly which kernel version you have. For instance, there's a lot of Rockchip modules in ayufan's kernel tree that just won't even compile in 138, you are not supposed to enable them. But I can see from the TRM that this board needs them. So a lot of functionality is still missing, or intentionally disabled for stability.
- You might also have to locate TRMs for arm's A53, and A57, and maybe another TRM for big.LITTLE architecture in general.
- But if you're an engineer and are inclined, who knows, you might stumble across a breakthrough in unlocking more performance. You might figure out why it's not doing what you expect.
Perhaps there will be some fortune, and you might find the missing piece.
http://opensource.rock-chips.com/wiki_Main_Page
In the SDK,
http://opensource.rock-chips.com/wiki_Linux_SDK
there are schematics and TRMs and such.
I have low programming skill, low engineering skill, no degrees, and I'm self-taught, but I'll dump out everything else that I can think of:
- I understand there is a big.LITTLE SMP scheduler module available in the kernel Kconfig, but I've never used it, because I can't personally use kernels beyond 4.4.138, and 138 doesn't have that scheduler yet. It DOES compile successfully though - maybe give that a shot once to see if it behaves differently. (But then other parts of the rk3399 won't be working right, such as HDMI audio.)
- I don't know if that scheduler will help what you're doing whatsoever.
- My assumption is that any code must know about, and actively choose to flip over to big cluster. Generally, since Linux tasks are small and numerous, 4 slower cores generally get more "done" than a faster set of 2 cores, so the 4 cores are the sensible default. Also, the big cluster requires more power to run, and being a SBC, you can see why they chose power savings by default, etc.
- There are several pieces that go along with big.LITTLE that are also not quite working yet in Linux kernels, and there's various levels of "working" depending on exactly which kernel version you have. For instance, there's a lot of Rockchip modules in ayufan's kernel tree that just won't even compile in 138, you are not supposed to enable them. But I can see from the TRM that this board needs them. So a lot of functionality is still missing, or intentionally disabled for stability.
- You might also have to locate TRMs for arm's A53, and A57, and maybe another TRM for big.LITTLE architecture in general.
- But if you're an engineer and are inclined, who knows, you might stumble across a breakthrough in unlocking more performance. You might figure out why it's not doing what you expect.