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

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

[viresh kumar]

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

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

[Sudeep KarkadaNagesha]

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
>

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

[Viresh Kumar]

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>
---

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

[Sudeep KarkadaNagesha]

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 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>
> ---
>
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

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

[Viresh Kumar]

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

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

[Viresh Kumar]

On 10 October 2012 19:37, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> 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.

Ahh, I was searching for something in my Archives and found this old
unanswered mail. As I have understood the difference between between
these two variables (affected and related cpus) now until this happened:
951fc5f4 (in v3.9). I thought it would be good to bury the actual answers
somewhere in Archives so that somebody looking for the answer can find
it easily.


What it was:

Affected CPUs: List of CPUs which share clock domain and s/w was responsible
to managing these.

Related CPUs: List of CPUs which share clock domain and only h/w was
responsible for managing these.

What do we mean by software and hardware managed stuff?

It was specific for acpi-cpufreq driver and nobody else :)

The firmware below kernel layer for hardware using this driver wanted to
manage cpus (sharing clock domain) by itself. i.e. It wanted the actual freq
request to go to it, it will then pick the highest freq requested for a clock
domain and set it for all cpus under policy->cpus. But kernel wouldn't know
these details at all. CPUFreq core would think that these cores don't
actually share clock line and so are independent.

Then there were some user space applications (like DVFS controllers),
which wanted to know the exact hardware coordination details rather than
what is present with cpufreq core. And so related_cpus was created for
them with this commit: e8628dd06d66f2e3965ec9742029b401d63434f1

related_cpus wasn't used in making kernel decisions at all and was only
for the applications who want to know exact hardware details.

As it didn't make sense to keep acpi-cpufreq specific stuff in CPUFreq core,
it was eventually moved into acpi-cpufreq driver with the name:
freqdomain_cpus in 3.11. related_cpus was kept in kernel but its meaning
is now changed.

affected_cpus: List of Online CPUs that require software coordination
of frequency.

related_cpus: List of Online + Offline CPUs that need software
coordination of frequency.

--
viresh