On Fri, Mar 20, 2015 at 12:33 PM, Michael Turquette mturquette@linaro.org wrote:
Quoting Juri Lelli (2015-03-20 07:54:10)
Hi Mike,
On 18/03/15 14:00, Mike Turquette wrote:
On Wed, Mar 18, 2015 at 4:55 AM, Juri Lelli juri.lelli@arm.com wrote:
Hi all,
On 18/03/15 08:36, Daniel Lezcano wrote:
I have an appointment at this time. Is it possible to delay *2* hours after ?
4:30PM GMT would work fine for us.
No problem. I have updated the meeting.
Thanks a lot again for organizing this meeting. Personally, it was really useful :).
So, we briefly mentioned that you were going to post a new version of sched-dvfs on eas-dev for further discussion. Do you have a rough idea of when you'll be able to do it?
The fact is that it would be nice to have this new version ready at the time EASv4 is going out on LKML. Since this is scheduled to happen by end of March, it would be really good to have the possibility to spend some time reviewing your new version and possibly adapt my deltas to it, I guess, next week :).
Hi Juri,
The meeting was very useful for me as well. I've been working to integrate all of the items we discussed into the next RFC. My hope is to publish to eas-dev for a first round of review and testing before I leave for ELC this weekend. The patches may be in a rough shape but I'll do my best.
Juri et al,
I've pushed code to my github tree under the branch "follow-the-capacity". This code badly needs to be rebased/squashed and may contain foul language and/or stream-of-conscious block comments.
This version has some notable changes:
1) no thresholds. After finding the most utilized cpu in the affected frequency domain we try to find the smallest capacity that is greater than that max_usage. In my smoke tests I found that PELT had no trouble hitting the highest OPP. I've left the up_thr code in there so you should still be able to play with it if you like.
2) no cpumasks exposed to scheduler. We just pass in a cpu (e.g. dst cpu via enqueue_task_fair after a load_balance). This code is significantly more elegant now (IMHO). If we need to evaluate frequency then we set the per-cpu pointer to the "need_task_wake" atomic_t and quickly return to the scheduler. All frequency evaluation takes place in the kthread. I have not yet implemented the non-blocking/async-dvfs code, but you can see comments for it; search for the conditional controller named "driver_might_sleep".
I've puts more block comments/kerneldoc in there. Hopefully it helps for you to understand the changes. I've only done a smoke test on Pandaboard ES:
echo cap_gov > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor echo SCHED_ENERGY_FREQ > /sys/kernel/debug/sched_features while [ 1 ]; do cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq; done
I'll rebase this and test on more hardware when I can. Now I must drive up to SF for ELC.
Regards, Mike
Regards, Mike
Thanks!
Best,
- Juri