On Mon, Jul 17, 2017 at 02:25:15PM +0100, Valentin Schneider wrote:
Hi,
On 12/07/17 22:04, Zachariah Kennedy wrote:
Good day!
I have been following EAS development for sometime now. Currently, I have implemented EAS in my own personal kernel for the Oneplus 3. It was largely based on the work done for the pixel and I am happy to say that currently, I have gotten better performance and battery life compared to stock CAF with HMP.
These questions will be based on the ACK android-4.4 branch
My first question is regarding tunings for EAS. I have seen many different values thrown around for awhile but I was curious about what everyone close to the project is using for schedutil up/down_rate_limit. Currently the stock values are 1000 (for up and down). Is this still the case for those testing the newest EAS changes using schedutil?
In another email, Andres has pointed out the parameters. But I noticed Andres pointed to "sched-freq" governor, but you are using schedutil. I have no much experience for these parameters tunning, but want to remind that Viresh found up/down_rate_limit is big number [1], I can see the parameters are 300ms on my board. This value may introduce long latency for frequency ramping up.
[1] https://lkml.org/lkml/2017/5/22/19
Also what about stune? I know stock pixel is using 50 for top-app\schedtune.boost for interactions but that turns out to be overkill with schedutil.
Lastly, I had purchased the Oneplus 5 with the SD835 just so I can port EAS to it as well. I am looking forward to testing how EAS scales with the extra cores to work with when compared to the SD820/821. One main questions regarding the SD835 is I wanted to see if anyone on the EAS-DEV list has developed an energy model for the SD835 (MSM8998). Even if it is just preliminary, I would appreciate any help with this. I do not have a proper energy meter yet.
Without any energy meter, you can still try to build a crude energy model using the P=C*f*V^2 formula. I've looked at something similar for the HiKey960, and the results were quite close to the "official" energy model. Mind you this will not give you idle or cluster costs - this will mostly be helpful to gauge the big vs LITTLE values. If you do end up getting an energy meter, we recommend the ACME: https://github.com/ARM-software/lisa/wiki/Energy-Meters-Requirements#iiocapt...
Just reminding one thing, if using a phone model rather than development board, usually it's hard to measure power by ARM energy probe or ACME.
To measure phone model, one possible method is to use power meter to supply power and measure power data, before I used [2] for this kind measurement; but the device is relative expensive and it is not supported by LISA or workload-automation for automatic testing. Another choice is to use ACME/arm energy probe to measure power, but this means you need find the measurement point with shunt resistor in the phone.
So as Valentin suggested, Hikey960 is easier for power modeling on it.
[2] https://www.msoon.com/LabEquipment/PowerMonitor/
Thanks, Leo Yan
What you need is the OPP tables of each cluster, which should be in the device tree - here's an example on HiKey960: https://android.googlesource.com/kernel/hikey-linaro/+/android-hikey-linaro-... This will give you 'f' and 'V' for each OPP. You might be able to find 'C' if your device uses IPA or a similar thermal management solution - it actually computes that C*f*V^2 formula, so it needs the 'C' listed somewhere. For IPA the dt-entry is 'dynamic-power-coefficient' and its value can be found for each cluster on the HiKey960: https://android.googlesource.com/kernel/hikey-linaro/+/android-hikey-linaro-...
As for the capacity values, you can try running a workload such as 'sysbench' at each OPP (using the userspace cpufreq governor) - your capacity value will be 1024 * (cur_opp_score / max_score). This is pretty much how we do it: https://github.com/ARM-software/lisa/blob/master/ipynb/energy/EnergyModel_Sy... (go to "Energy Model Generation")
This is something I am truly interested in. I love the openness of all the Devs close to this project. I have become a better developer having participated and watching from the sidelines. Thanks guys for your hard work.
Kind Regards, Zachariah Kennedy _______________________________________________ eas-dev mailing list eas-dev@lists.linaro.org https://lists.linaro.org/mailman/listinfo/eas-dev
eas-dev mailing list eas-dev@lists.linaro.org https://lists.linaro.org/mailman/listinfo/eas-dev