Re: [Eas-dev] delaying update of setting OPP

On Wed, Nov 11, 2015 at 05:28:50PM -0800, Steve Muckle wrote:

In cpufreq_sched_set_cap we currently have this:

/*

• We only change frequency if this cpu's capacity request represents a
• new max. If another cpu has requested a capacity greater than the
• previous max then we rely on that cpu to hit this code path and make
• the change. IOW, the cpu with the new max capacity is responsible
• for setting the new capacity/frequency.
• If this cpu is not the new maximum then bail

*/ if (capacity_max > capacity) goto out;

But this can lead to situations like (2 CPU cluster, CPUs start with cap request of 0):

1. CPU0 gets heavily loaded, requests cap = 1024 (fmax)
2. CPU1 gets lightly loaded, requests cap = 10
3. CPU0's load goes away, requests cap = 0
4. CPU1's load of 10 persists for a long time

In step #3 we could've set the cluster capacity to 10/1024 but did not because the CPU we were working with at the time (CPU0) was not the CPU driving the new cluster maximum capacity request. As a result we run unnecessarily at fmax for a long time.

Any reason to not set the OPP associated with the new max capacity request immediately, regardless of what CPU is driving it?

Good finding, this code is a optimization for increasing OPP, maybe it also introduce bug for downgrading OPP?

Thanks, Leo Yan