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
--
To unsubscribe from this list: send the line "unsubscribe cpufreq" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
