On 08-01-18, 16:11, Patrick Bellasi wrote:
On 05-Jan 16:13, Viresh Kumar wrote:
I don't have access to this report... just sent a requests.
I thought I shared it correctly earlier but looks like it was set to "Anyone with link from Linaro". Fixed it now.
How to replicate setup:
Android kernel tree: https://git.linaro.org/people/vireshk/mylinux.git android-4.9-hikey
This has several patches over latest 4.9-hikey aosp tree.
Some patches to reduce disturbances, which Vincent shared earlier with a document.
"thermal: Add debugfs support for cooling devices" and "cpufreq: stats: New sysfs attribute for clearing statistics" are used to read some more data from userspace after tests are done which can be used to build conclusions on working of pelt/walt and how they are behaving differently.
For example, we can know the amount of time we spent on individual cpu frequencies while the test was running. And also the time for which cpu-cooling and devfreq (ddr) has throttled some frequencies.
Pelt 16 and pelt 8 patches.
Are those the patches I've shared few weeks ago, on top of util_est?
http://www.linux-arm.org/git?p=linux-pb.git%3Ba=shortlog%3Bh=refs/heads/eas/...
Ah no. I never saw yours and created my own :)
I even uploaded a very similar patch for inclusion in the Android tree yesterday.
https://android-review.googlesource.com/c/kernel/common/+/581203
Just reinvented the wheel it seems :(
There are two main observations regarding PELT speedups:
faster decay time: by speeding up the ramp-up we also have faster decay times, which ultimately make PELT even more different than WALT, where instead utilization never decays. This can benefits benchmarks but can affect other interactive use-cases.
the constants you change affects LOAD too, do we know what are the side-effects in this case?
Moreover, as Leo pointed out, speeding up PELT can also have side effects on overutilization, thus reducing the time we run in energy aware mode.
I agree.
All that considered, IMHO evaluating PELT speed-up requires a much more extensive set of tests then just comparing 3 runs of PCMark.
Sure. I just wanted to start an initial discussion to get some feedback on the direction of the work I was doing.
Do we need another one? Can't you share instead wltest results?
I have used only WA for these tests, but yeah wltest/lisa would be better.
That's also what ultimately Google want to see as experimental evaluation of scheduler propose modifications.
I heard from Vincent earlier that ARM did similar testing earlier on but never found anything significant. Why ? I may have an answer to that, not sure though.
That's not completely true, we did testing and we are doing testing. The branch above is part of the testing we are doing, on both PELT speed-ups and util_est, which we still consider as part of the same story to have a more WALT-like PELT.
Hmm, I had a chat around this long back with Vincent and was under the impression that ARM hasn't found much value in playing with half-life period. Of course, I didn't knew the above stuff.
Regarding the results however there was benefits, and that's why Pixel phones have been released with a 16ms PELT.
Aren't the pixel phones using WALT for cpu and task utill stuff ?
-- viresh