Hi Dietmar,
On Fri, Aug 21, 2015 at 07:09:09AM -0700, Dietmar Eggemann wrote:
On 08/21/2015 12:57 AM, Leo Yan wrote:
[...]
Hardware Environment
- Platform: 96boards Hikey
- SoC: Hi6220, 2 clusters, 4xCA53 CPUs in each cluster
- CPU clock: 2 clusters with 8 CPUs have coupled clock source and support 208mHz/432mHz/729mHz/960mHz/1200mHz
- Support CPU and cluster level low power mode
Software Environment
- Kernel: 4.2rc4 + EAS RFCv5
Could you share the platform adaptation code [especially arch/arm64/kernel/topology.c]. I'm interested in the Energy Model you're using and where you put the SD_SHARE_CAP_STATES sd flag :-)
Thanks for reminding, directly used the same energy model with Juno which Juri shared with me. I recognized need change code like below so that can best match for my case; will do second round profiling and update with you.
That's true for this platform. The direct dependency is in sched_group_energy():
5051 /* 5052 * Is the group utilization affected by cpus outside this 5053 * sched_group? 5054 */ 5055 sd = highest_flag_domain(cpu, SD_SHARE_CAP_STATES);
Since you can't measure power on this board yet you can't create your own EM. Using the Juno one is fine but you have to adapt the 'struct capacity_state' arrays for the A53 and the clusters.
You have '208mHz/432mHz/729mHz/960mHz/1200mHz' whereas the A53 on Juno R0 has '450000 575000 700000 775000 850000'
So both have 5 OPPs. That means you could just take the values from Juno except the fact that the highest OPP on A53 does not have a .cap value of 1024 because on Juno you have the big cluster as well. I would rescale the .cap values to 1024 for the highest OPP, just to be save. The A53 at 1200000 is the highest capacity value available so it should be 1024. Maybe you did this already ...
No, i will adjust them.
Another thing ... Did you adapt the rt-app-X.json files to 8 cpus?
No, still only create 5 threads; So need create 8 threads instead.
Looks like my first round profiling is quite rough, will do second round with more careful parameters for energy model; your detailed review is very helpful :)
BTW, i saw Morten's patch series have some performance comaparsion for sysbench and rt-app's cases, like below table's colume "prf"; so could you help explain how to get these performance result?
Energy Mainline (ndm) noEAS (ndm) EAS (ndm) EAS (sched) nrg prf nrg prf nrg prf nrg prf sysbench 100 100 107 105 108 105 107 105
rt-app mp3 100 n.a. 101 n.a. 45 n.a. 43 n.a.
rt-app 6% 100 85 103 85 31 60 33 59 rt-app 13% 100 76 102 76 39 46 41 50 rt-app 19% 100 64 102 64 93 54 93 54 rt-app 25% 100 53 102 53 93 43 96 45 rt-app 31% 100 44 102 43 115 35 145 43 rt-app 38% 100 35 116 32 113 2 140 29 rt-app 44% 100 -40k 142 -9k 141 -9k 145 -1k rt-app 50% 100 -100k 133 -21k 131 -22k 131 -4k
Thanks, Leo Yan