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