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. - 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
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
On 10 October 2012 17:31, Sudeep KarkadaNagesha Sudeep.KarkadaNagesha@arm.com wrote:
On 08/10/12 14:58, viresh kumar wrote:
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 ?
Code.
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.
Probably yes. I was wrong.
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.
I couldn't understand the difference b/w h/w and s/w coordination. What do we mean by them here.
Following patch added related related_cpu stuff:
commit e8628dd06d66f2e3965ec9742029b401d63434f1 Author: Darrick J. Wong djwong@us.ibm.com Date: Fri Apr 18 13:31:12 2008 -0700
[CPUFREQ] expose cpufreq coordination requirements regardless of coordination mechanism
Currently, affected_cpus shows which CPUs need to have their frequency coordinated in software. When hardware coordination is in use, the contents of this file appear the same as when no coordination is required. This can lead to some confusion among user-space programs, for example, that do not know that extra coordination is required to force a CPU core to a particular speed to control power consumption.
To fix this, create a "related_cpus" attribute that always displays the coordination map regardless of whatever coordination strategy the cpufreq driver uses (sw or hw). If the cpufreq driver does not provide a value, fall back to policy->cpus.
Signed-off-by: Darrick J. Wong djwong@us.ibm.com Signed-off-by: Andrew Morton akpm@linux-foundation.org Signed-off-by: Dave Jones davej@redhat.com ---
On 10/10/12 14:26, Viresh Kumar wrote: [...]
I couldn't understand the difference b/w h/w and s/w coordination. What do we mean by them here.
Following patch added related related_cpu stuff:
commit e8628dd06d66f2e3965ec9742029b401d63434f1 Author: Darrick J. Wong djwong@us.ibm.com Date: Fri Apr 18 13:31:12 2008 -0700
[CPUFREQ] expose cpufreq coordination requirements regardless ofcoordination mechanism
Currently, affected_cpus shows which CPUs need to have their frequency coordinated in software. When hardware coordination is in use, the contents of this file appear the same as when no coordination is required. This can lead to some confusion among user-space programs, for example, that do not know that extra coordination is required to force a CPU core to a particular speed to control power consumption. To fix this, create a "related_cpus" attribute that always displays the coordination map regardless of whatever coordination strategy the cpufreq driver uses (sw or hw). If the cpufreq driver does not provide avalue, fall back to policy->cpus.
Signed-off-by: Darrick J. Wong <djwong@us.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Dave Jones <davej@redhat.com>
Here is my understanding on this patch. This change is closely related to ACPI cpufreq driver(used mostly on Intel cores). This change was introduced to keep track of the related cpus as returned by ACPI firmware along with affected cpus as imposed by SW. I don't understand the exact difference in Intel cores. I believe it's just for tracking and not used much in the driver.
Regards, Sudeep
On 10 October 2012 19:14, Sudeep KarkadaNagesha Sudeep.KarkadaNagesha@arm.com wrote:
Here is my understanding on this patch. This change is closely related to ACPI cpufreq driver(used mostly on Intel cores). This change was introduced to keep track of the related cpus as returned by ACPI firmware along with affected cpus as imposed by SW. I don't understand the exact difference in Intel cores. I believe it's just for tracking and not used much in the driver.
Then i believe we shouldn't fill the related_cpus field for ARM cores. As anyway the show_related_cpus will pick affected cpus in that case.
-- viresh
-
Sudeep KarkadaNagesha -
Viresh Kumar -
viresh kumar