Re: [PATCH V2 06/10] cpufreq: governor: Keep single copy of information common to policy->cpus

[Saravana Kannan <skannan@codeaurora.org>]

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

-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project