Hi Juri, Steve,
It looks like if cpuX sets its own OPP level in task_tick_fair (to capacity_orig), another cpuY can override this to any value (at least via enqueue_task_fair) before cpuX's request can take effect (i.e. before the throttling timestamp is updated via the kcpufreq thread). The request from cpuX at the next tick may be throttled or the task may go to sleep and its load is decayed enough that the next request after wakeup no longer crosses the threshold and hence we lose the opportunity to go to FMAX. It seems like we need to have a mechanism where a current higher request from cpu for its own capacity should override any other cpu's lower request?
Thanks, Vikram
Hi Vikram,
On 11/13/2015 06:50 PM, Vikram Mulukutla wrote:
It looks like if cpuX sets its own OPP level in task_tick_fair (to capacity_orig), another cpuY can override this to any value (at least via enqueue_task_fair) before cpuX's request can take effect (i.e. before the throttling timestamp is updated via the kcpufreq thread). The request from cpuX at the next tick may be throttled or the task may go to sleep and its load is decayed enough that the next request after wakeup no longer crosses the threshold and hence we lose the opportunity to go to FMAX. It seems like we need to have a mechanism where a current higher request from cpu for its own capacity should override any other cpu's lower request?
What version of the code are you working off of?
The code posted to lkml has an assortment of known issues, some of which I've addressed and pushed to
https://git.linaro.org/people/steve.muckle/kernel.git
but there's still the issue about frequency management when a CPU goes idle. This really needs to be addressed before meaningful profiling can be done. I also have a couple more fixes I have not yet pushed.
On 11/13/2015 7:07 PM, Steve Muckle wrote:
Hi Vikram,
On 11/13/2015 06:50 PM, Vikram Mulukutla wrote:
It looks like if cpuX sets its own OPP level in task_tick_fair (to capacity_orig), another cpuY can override this to any value (at least via enqueue_task_fair) before cpuX's request can take effect (i.e. before the throttling timestamp is updated via the kcpufreq thread). The request from cpuX at the next tick may be throttled or the task may go to sleep and its load is decayed enough that the next request after wakeup no longer crosses the threshold and hence we lose the opportunity to go to FMAX. It seems like we need to have a mechanism where a current higher request from cpu for its own capacity should override any other cpu's lower request?
What version of the code are you working off of?
The code posted to lkml has an assortment of known issues, some of which I've addressed and pushed to
Thanks Steve. I've been working off of the 3.18 backport on the chromium server. It doesn't have the fixes you're referring to, although I've made a few similar changes locally. I'll try porting your fixes over, but would you know if there's a plan to backport updates to 3.18 again at some point?
Thanks, Vikram
On 11/17/2015 01:10 PM, Vikram Mulukutla wrote:
The code posted to lkml has an assortment of known issues, some of which I've addressed and pushed to
Thanks Steve. I've been working off of the 3.18 backport on the chromium server. It doesn't have the fixes you're referring to, although I've made a few similar changes locally. I'll try porting your fixes over, but would you know if there's a plan to backport updates to 3.18 again at some point?
I recall a 3.18 support branch being mentioned at one point but I don't know the details. Things are currently focused on tip AFAIK.
Hi guys.
On 19 Nov 2015, at 02:14, Steve Muckle steve.muckle@linaro.org wrote:
On 11/17/2015 01:10 PM, Vikram Mulukutla wrote:
The code posted to lkml has an assortment of known issues, some of which I've addressed and pushed to
Thanks Steve. I've been working off of the 3.18 backport on the chromium server. It doesn't have the fixes you're referring to, although I've made a few similar changes locally. I'll try porting your fixes over, but would you know if there's a plan to backport updates to 3.18 again at some point?
I recall a 3.18 support branch being mentioned at one point but I don't know the details. Things are currently focused on tip AFAIK.
There’s a discussion underway to create an 3.18 Linaro LSK using the ChromeOS EAS 3.18 branch as a seed. Over time, we would like to take features that emerge against tip/sched/core into the 3.18 LSK branch (and vice versa as things transpire).
Once the discussion matures a bit, we’ll provide pointers to the EAS LSK branch structure.
Robin
________________________________
-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
-
Robin Randhawa -
Steve Muckle -
Vikram Mulukutla