+333
−369
File changed.
Preview size limit exceeded, changes collapsed.
Loading
Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more
Interactive governor currently uses per-cpu timer to evaluate each CPU's frequency. For policies that manages multiples CPUs, each CPU runs its own algorithm to decide its frequency and then final result is aggregated in speedchange task. This implementation has a few drawbacks. Due to the use of deferrable timers, timers between CPUs can be easily misaligned. If a load migrates from CPU A to CPU B, there exists a gap where CPU A could have dropped its frequency vote yet CPU B hasn't seen the demand to ramp up its vote. This would result in an incorrect drop in policy frequency which is harmful for performance. In addition, for CPU waking up in middle of a window, the timestamps it takes will not be aligned with jiffy boundaries, and thus when next time timer fires, it could incorrectly prevent frequency ramp up/down for one more window. Change-Id: Ia82c7b0cff5bb1ea165fb83fbb7a5546ea7d0396 [junjiew@codeaurora.org: Resolved merge conflicts. ] Signed-off-by:Junjie Wu <junjiew@codeaurora.org> Signed-off-by:
Stephen Boyd <sboyd@codeaurora.org>
File changed.
Preview size limit exceeded, changes collapsed.