Re: [Query]: CPUFREQ: Affected and related cpus in cpufreq

[Sudeep KarkadaNagesha <Sudeep.KarkadaNagesha-5wv7dgnIgG8@public.gmane.org>]

Hi Viresh,

On 08/10/12 14:58, viresh kumar wrote:
> Hi All,
>
> Sorry for  asking one of the most basic question of cpufreq :(
>
> I couldn't get the difference between affected (policy->cpus) and
> related cpus (policy->related_cpus) in cpufreq...
>
> As per Documentation/code:
>
> affected_cpus(policy->cpus):
> - List of CPUs that require software coordination of frequency.
> - Processors part of affected_cpus share policy struct
> - Policy limits the frequencies that the processor can work with.
>
> related_cpus(policy->related_cpus):
> - List of CPUs that need some sort of frequency coordination, whether
>    software or hardware.
> - Processors part of related_cpus share governer.
Which document states this ?

As per my understanding and if you see in cpufreq.c, related_cpus are
used only when adding back the hotplugged cpu to get the governor.
Elsewhere affected_cpus is used.

Ideally it would be good if above statements is true.
E.g. In SMP with 4 CPUs(with same OPPs), if 0-1 and 2-3 need h/w 
co-ordination, then:
related_cpus: 0-1 and 2-3
affected_cpus: case#1: 0-1 and 2-3 if we want to have different policies
	       case#2: 0-3 if we want to have same policy on all CPUS
I believe this is not possible in current code.

> - Governer sets the rules, about when to change limits specified by policy.
>
> Correct?
>
> So, now comes the real question:
> - In which scenario's should we populate affected and related cpus?
> - Should related cpus will always be a superset of affected cpus?
>
> --
> Viresh
>