Hi Steve,
On 11/11/15, 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):
- CPU0 gets heavily loaded, requests cap = 1024 (fmax)
- CPU1 gets lightly loaded, requests cap = 10
- CPU0's load goes away, requests cap = 0
- 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.
CPU1's tasks sleeps, since utilization is low. Don't we re-evaluate the request as soon as someone goes to sleep/wakes up?
Any reason to not set the OPP associated with the new max capacity request immediately, regardless of what CPU is driving it?
OTOH, what you say makes sense too, it should be safe to go to 10/1024 as soon as CPU0 becomes idle.
Thanks,
- Juri