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