On 12/02/2015 10:53 PM, Robert Schöne wrote:
There is another idea that I have.
Lets sacrifice idleness of CPU0 (which is already considered as housekeeping CPU in scheduler) to save us from all the complexity we have today.
Suppose we have 16 CPUs, with 4 CPUs per policy and hence 4 policies.
- Keep a single delayed-work (non-deferrable) per policy and queue
them as:
This is a 100% no go. Non-deferrable is going to kill mobile idle power.
queue_work_on(CPU0).
- This will work because any CPU can calculate the load of other
CPUs, and there is no dependency on the local CPU.
- CPU0 will hence get interrupted, check if the policy->cpus are idle or not, and if not, update their frequency (perhaps with an IPI).
Not sure if this will be better performance wise though.
No it is not. In your example, everything could be okay with many ifs. I'm from the HPC field and would expect load imbalances because this approach does not scale with the number of frequency domains.
Agree. I think that's why we had per policy timers (forced to be implemented with per CPU deferrable timers) in the first place.
-Saravana