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