Clarification on the DVFS capabilities

Clarification on the DVFS capabilities

[karthik vm]

Hi,

I have few doubts on the DVFS capabilities of my intel Core2Duo
processor (T5750) which has 2 cores (no hyperthreading) and has
Enhanced Intel Speed Step Technology (EIST). When I run the
"cpufreq-info" command in Ubuntu Linux I get the result that: "CPUs
which run at the same hardware frequency: 0 1". Hence I assumed that
both the CPUs will increase and decrease the frequency in a
synchronous fashion.

But when I tried to verify it by using the below command:

$ watch -n 0.1 grep \"cpu MHz\" /proc/cpuinfo

Here I see that each core is varying the frequency individually
contrary to the cpufreq-info commands output that both run at the same
hardware frequency. Hence can anyone comment on this behavior?

Regards,
karthik

Re: Clarification on the DVFS capabilities

[Viresh Kumar]

On Tue, May 21, 2013 at 9:48 PM, karthik vm <meetvm@gmail.com> wrote:
> I have few doubts on the DVFS capabilities of my intel Core2Duo
> processor (T5750) which has 2 cores (no hyperthreading) and has
> Enhanced Intel Speed Step Technology (EIST). When I run the
> "cpufreq-info" command in Ubuntu Linux I get the result that: "CPUs
> which run at the same hardware frequency: 0 1". Hence I assumed that
> both the CPUs will increase and decrease the frequency in a
> synchronous fashion.
>
> But when I tried to verify it by using the below command:
>
> $ watch -n 0.1 grep \"cpu MHz\" /proc/cpuinfo
>
> Here I see that each core is varying the frequency individually
> contrary to the cpufreq-info commands output that both run at the same
> hardware frequency. Hence can anyone comment on this behavior?

Which kernel version are you using? Can you paste output of cpufreq-info.
You need to look at: "CPUs which need to have their frequency
coordinated by software:"
to get the right group of cpus..

The other group (pointed by you) had misleading values, which are
recently fixed in 3.9.

Re: Clarification on the DVFS capabilities

[karthik vm]

Hi Viresh,

Thanks for your quick reply. The output of cpufreq-info command is as below:
--------------------------------------------------------------------
$ cpufreq-info
cpufrequtils 007: cpufreq-info (C) Dominik Brodowski 2004-2009
Report errors and bugs to cpufreq@vger.kernel.org, please.
analyzing CPU 0:
  driver: acpi-cpufreq
  CPUs which run at the same hardware frequency: 0 1
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency: 10.0 us.
  hardware limits: 1000 MHz - 2.00 GHz
  available frequency steps: 2.00 GHz, 1.67 GHz, 1.33 GHz, 1000 MHz
  available cpufreq governors: conservative, ondemand, userspace,
powersave, performance
  current policy: frequency should be within 1000 MHz and 2.00 GHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 2.00 GHz.
  cpufreq stats: 2.00 GHz:7.39%, 1.67 GHz:0.66%, 1.33 GHz:1.23%, 1000
MHz:90.72%  (48956)
analyzing CPU 1:
  driver: acpi-cpufreq
  CPUs which run at the same hardware frequency: 0 1
  CPUs which need to have their frequency coordinated by software: 1
  maximum transition latency: 10.0 us.
  hardware limits: 1000 MHz - 2.00 GHz
  available frequency steps: 2.00 GHz, 1.67 GHz, 1.33 GHz, 1000 MHz
  available cpufreq governors: conservative, ondemand, userspace,
powersave, performance
  current policy: frequency should be within 1000 MHz and 2.00 GHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 2.00 GHz.
  cpufreq stats: 2.00 GHz:5.87%, 1.67 GHz:0.22%, 1.33 GHz:0.35%, 1000
MHz:93.55%  (10792)
----------------------------------------------------------------------------------

Also my current Linux version is 3.2.0-43-generic. May be thats why
there are misleading values for "CPUs which run at the same hardware
frequency".

Hence I guess that in my case "CPUs which run at the same hardware
frequency" & "CPUs which need to have their frequency coordinated by
software" should have the same value. If so this means that the CPU
has per-core DVFS. Please correct me if I am wrong.

Regards,
karthik

On Wed, May 22, 2013 at 12:08 AM, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> On Tue, May 21, 2013 at 9:48 PM, karthik vm <meetvm@gmail.com> wrote:
>> I have few doubts on the DVFS capabilities of my intel Core2Duo
>> processor (T5750) which has 2 cores (no hyperthreading) and has
>> Enhanced Intel Speed Step Technology (EIST). When I run the
>> "cpufreq-info" command in Ubuntu Linux I get the result that: "CPUs
>> which run at the same hardware frequency: 0 1". Hence I assumed that
>> both the CPUs will increase and decrease the frequency in a
>> synchronous fashion.
>>
>> But when I tried to verify it by using the below command:
>>
>> $ watch -n 0.1 grep \"cpu MHz\" /proc/cpuinfo
>>
>> Here I see that each core is varying the frequency individually
>> contrary to the cpufreq-info commands output that both run at the same
>> hardware frequency. Hence can anyone comment on this behavior?
>
> Which kernel version are you using? Can you paste output of cpufreq-info.
> You need to look at: "CPUs which need to have their frequency
> coordinated by software:"
> to get the right group of cpus..
>
> The other group (pointed by you) had misleading values, which are
> recently fixed in 3.9.

Re: Clarification on the DVFS capabilities

[Dirk Brandewie]

On 05/22/2013 09:28 AM, karthik vm wrote:
> Hi Viresh,
>
> Thanks for your quick reply. The output of cpufreq-info command is as below:
> --------------------------------------------------------------------
> $ cpufreq-info
> cpufrequtils 007: cpufreq-info (C) Dominik Brodowski 2004-2009
> Report errors and bugs to cpufreq@vger.kernel.org, please.
> analyzing CPU 0:
>    driver: acpi-cpufreq
>    CPUs which run at the same hardware frequency: 0 1
>    CPUs which need to have their frequency coordinated by software: 0
>    maximum transition latency: 10.0 us.
>    hardware limits: 1000 MHz - 2.00 GHz
>    available frequency steps: 2.00 GHz, 1.67 GHz, 1.33 GHz, 1000 MHz
>    available cpufreq governors: conservative, ondemand, userspace,
> powersave, performance
>    current policy: frequency should be within 1000 MHz and 2.00 GHz.
>                    The governor "ondemand" may decide which speed to use
>                    within this range.
>    current CPU frequency is 2.00 GHz.
>    cpufreq stats: 2.00 GHz:7.39%, 1.67 GHz:0.66%, 1.33 GHz:1.23%, 1000
> MHz:90.72%  (48956)
> analyzing CPU 1:
>    driver: acpi-cpufreq
>    CPUs which run at the same hardware frequency: 0 1
>    CPUs which need to have their frequency coordinated by software: 1
>    maximum transition latency: 10.0 us.
>    hardware limits: 1000 MHz - 2.00 GHz
>    available frequency steps: 2.00 GHz, 1.67 GHz, 1.33 GHz, 1000 MHz
>    available cpufreq governors: conservative, ondemand, userspace,
> powersave, performance
>    current policy: frequency should be within 1000 MHz and 2.00 GHz.
>                    The governor "ondemand" may decide which speed to use
>                    within this range.
>    current CPU frequency is 2.00 GHz.
>    cpufreq stats: 2.00 GHz:5.87%, 1.67 GHz:0.22%, 1.33 GHz:0.35%, 1000
> MHz:93.55%  (10792)
> ----------------------------------------------------------------------------------
>
> Also my current Linux version is 3.2.0-43-generic. May be thats why
> there are misleading values for "CPUs which run at the same hardware
> frequency".
>
> Hence I guess that in my case "CPUs which run at the same hardware
> frequency" & "CPUs which need to have their frequency coordinated by
> software" should have the same value. If so this means that the CPU
> has per-core DVFS. Please correct me if I am wrong.
>

cpufreq stats reports the frequency that was requested on each core.

The governor will request a frequency per core.

The actual frequency that the core/package runs at is coordinated by the
CPU itself based on the all the core requests.

There is no way (that I know of) to get the current frequency a given core is
running at.



> Regards,
> karthik
>
> On Wed, May 22, 2013 at 12:08 AM, Viresh Kumar <viresh.kumar@linaro.org> wrote:
>> On Tue, May 21, 2013 at 9:48 PM, karthik vm <meetvm@gmail.com> wrote:
>>> I have few doubts on the DVFS capabilities of my intel Core2Duo
>>> processor (T5750) which has 2 cores (no hyperthreading) and has
>>> Enhanced Intel Speed Step Technology (EIST). When I run the
>>> "cpufreq-info" command in Ubuntu Linux I get the result that: "CPUs
>>> which run at the same hardware frequency: 0 1". Hence I assumed that
>>> both the CPUs will increase and decrease the frequency in a
>>> synchronous fashion.
>>>
>>> But when I tried to verify it by using the below command:
>>>
>>> $ watch -n 0.1 grep \"cpu MHz\" /proc/cpuinfo
>>>
>>> Here I see that each core is varying the frequency individually
>>> contrary to the cpufreq-info commands output that both run at the same
>>> hardware frequency. Hence can anyone comment on this behavior?
>>
>> Which kernel version are you using? Can you paste output of cpufreq-info.
>> You need to look at: "CPUs which need to have their frequency
>> coordinated by software:"
>> to get the right group of cpus..
>>
>> The other group (pointed by you) had misleading values, which are
>> recently fixed in 3.9.
> --
> To unsubscribe from this list: send the line "unsubscribe cpufreq" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: Clarification on the DVFS capabilities

[karthik vm]

Thanks for the info Dirk. Basically I wanted to know whether the
frequency of each of my multi-core chip can be changed individually
(per-core DVFS) or the frequency can be changed on all cores
simultaneously (chip wide DVFS).

Based on cpufreq-info command's "CPUs which need to have their
frequency coordinated by software" output as pointed by Viresh says
that each core is individually controlled by software. Hence it is
per-core DVFS. And it confirms with my experimental result also. But I
got confused from "CPUs which run at the same hardware frequency"
output which says both cores which mean chip-wide DVFS. Now I got
cleared up as this has misleading values.

Thanks for your insights.

Regards,
karthik

On Wed, May 22, 2013 at 12:46 PM, Dirk Brandewie
<dirk.brandewie@gmail.com> wrote:
> On 05/22/2013 09:28 AM, karthik vm wrote:
>>
>> Hi Viresh,
>>
>> Thanks for your quick reply. The output of cpufreq-info command is as
>> below:
>> --------------------------------------------------------------------
>> $ cpufreq-info
>> cpufrequtils 007: cpufreq-info (C) Dominik Brodowski 2004-2009
>> Report errors and bugs to cpufreq@vger.kernel.org, please.
>> analyzing CPU 0:
>>    driver: acpi-cpufreq
>>    CPUs which run at the same hardware frequency: 0 1
>>    CPUs which need to have their frequency coordinated by software: 0
>>    maximum transition latency: 10.0 us.
>>    hardware limits: 1000 MHz - 2.00 GHz
>>    available frequency steps: 2.00 GHz, 1.67 GHz, 1.33 GHz, 1000 MHz
>>    available cpufreq governors: conservative, ondemand, userspace,
>> powersave, performance
>>    current policy: frequency should be within 1000 MHz and 2.00 GHz.
>>                    The governor "ondemand" may decide which speed to use
>>                    within this range.
>>    current CPU frequency is 2.00 GHz.
>>    cpufreq stats: 2.00 GHz:7.39%, 1.67 GHz:0.66%, 1.33 GHz:1.23%, 1000
>> MHz:90.72%  (48956)
>> analyzing CPU 1:
>>    driver: acpi-cpufreq
>>    CPUs which run at the same hardware frequency: 0 1
>>    CPUs which need to have their frequency coordinated by software: 1
>>    maximum transition latency: 10.0 us.
>>    hardware limits: 1000 MHz - 2.00 GHz
>>    available frequency steps: 2.00 GHz, 1.67 GHz, 1.33 GHz, 1000 MHz
>>    available cpufreq governors: conservative, ondemand, userspace,
>> powersave, performance
>>    current policy: frequency should be within 1000 MHz and 2.00 GHz.
>>                    The governor "ondemand" may decide which speed to use
>>                    within this range.
>>    current CPU frequency is 2.00 GHz.
>>    cpufreq stats: 2.00 GHz:5.87%, 1.67 GHz:0.22%, 1.33 GHz:0.35%, 1000
>> MHz:93.55%  (10792)
>>
>> ----------------------------------------------------------------------------------
>>
>> Also my current Linux version is 3.2.0-43-generic. May be thats why
>> there are misleading values for "CPUs which run at the same hardware
>> frequency".
>>
>> Hence I guess that in my case "CPUs which run at the same hardware
>> frequency" & "CPUs which need to have their frequency coordinated by
>> software" should have the same value. If so this means that the CPU
>> has per-core DVFS. Please correct me if I am wrong.
>>
>
> cpufreq stats reports the frequency that was requested on each core.
>
> The governor will request a frequency per core.
>
> The actual frequency that the core/package runs at is coordinated by the
> CPU itself based on the all the core requests.
>
> There is no way (that I know of) to get the current frequency a given core
> is
> running at.
>
>
>
>> Regards,
>> karthik
>>
>> On Wed, May 22, 2013 at 12:08 AM, Viresh Kumar <viresh.kumar@linaro.org>
>> wrote:
>>>
>>> On Tue, May 21, 2013 at 9:48 PM, karthik vm <meetvm@gmail.com> wrote:
>>>>
>>>> I have few doubts on the DVFS capabilities of my intel Core2Duo
>>>> processor (T5750) which has 2 cores (no hyperthreading) and has
>>>> Enhanced Intel Speed Step Technology (EIST). When I run the
>>>> "cpufreq-info" command in Ubuntu Linux I get the result that: "CPUs
>>>> which run at the same hardware frequency: 0 1". Hence I assumed that
>>>> both the CPUs will increase and decrease the frequency in a
>>>> synchronous fashion.
>>>>
>>>> But when I tried to verify it by using the below command:
>>>>
>>>> $ watch -n 0.1 grep \"cpu MHz\" /proc/cpuinfo
>>>>
>>>> Here I see that each core is varying the frequency individually
>>>> contrary to the cpufreq-info commands output that both run at the same
>>>> hardware frequency. Hence can anyone comment on this behavior?
>>>
>>>
>>> Which kernel version are you using? Can you paste output of cpufreq-info.
>>> You need to look at: "CPUs which need to have their frequency
>>> coordinated by software:"
>>> to get the right group of cpus..
>>>
>>> The other group (pointed by you) had misleading values, which are
>>> recently fixed in 3.9.
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe cpufreq" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>

Re: Clarification on the DVFS capabilities

[Viresh Kumar]

On 22 May 2013 21:58, karthik vm <meetvm@gmail.com> wrote:
> Hi Viresh,
>
> Thanks for your quick reply. The output of cpufreq-info command is as below:

So output says exactly what I said to you.

Re: Clarification on the DVFS capabilities

[karthik vm]

Thanks for the pointers. I got my doubts cleared. I have one final
question on EIST which I am still looking for an answer.

In the article (http://software.intel.com/en-us/articles/enhanced-intel-speedstepr-technology-and-demand-based-switching-on-linux/)
the author says that voltage and frequency changes are separated. Does
this mean that even though a chip has chip-wide DVFS where the voltage
is changed simultaneously across all cores, the frequency of each core
can be still changed individually? Kindly let me know your comments.

Thanks,
karthik

On Thu, May 23, 2013 at 6:12 AM, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> On 22 May 2013 21:58, karthik vm <meetvm@gmail.com> wrote:
>> Hi Viresh,
>>
>> Thanks for your quick reply. The output of cpufreq-info command is as below:
>
> So output says exactly what I said to you.

Re: Clarification on the DVFS capabilities

[Viresh Kumar]

On 23 May 2013 22:21, karthik vm <meetvm@gmail.com> wrote:
> In the article (http://software.intel.com/en-us/articles/enhanced-intel-speedstepr-technology-and-demand-based-switching-on-linux/)
> the author says that voltage and frequency changes are separated. Does
> this mean that even though a chip has chip-wide DVFS where the voltage
> is changed simultaneously across all cores, the frequency of each core
> can be still changed individually? Kindly let me know your comments.

Dirk is an Intel expert and I am not :)

But, this is what is present at the link you gave:

"Separation between Voltage and Frequency Changes. By stepping voltage
up and down in small increments separately from frequency changes, the
processor is able to reduce periods of system unavailability (which
occur during frequency change). Thus, the system is able to transition
between voltage and frequency states more often, providing improved
power/performance balance.
"

And this probably means voltage/freq can be changed in small steps
independently to each other.. So that when you change freq you don't
necessarily change voltage..

eg: You want to go to a high freq..and you need high voltage for it..
- So increase voltage in small steps first.. so that freq line stays
stable and processor can work during that time..
- Now change freq and it may put cpu on idle for some time..

I couldn't make out if it said something about multiple cpus DVFS.

Re: Clarification on the DVFS capabilities

[karthik vm]

Thanks for your insights Viresh. I really appreciate it!!

Basically I wanted to know the DVFS granularity of a multi-core chip.
i.e I want to know whether every core can separately increase or
decrease its frequency or all the cores increase or decrease
simultaneously. I think cpufreq-info command's output "CPUs which need
to have their frequency coordinated by software" gives the answer. For
my core2duo processor it says either core 0 or core 1. Hence frequency
of each of my cores can be changed individually. Experimental results
also supports it. Please correct me if there is any fallacy in my
inference.

Regards,
karthik

On Fri, May 24, 2013 at 1:24 AM, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> On 23 May 2013 22:21, karthik vm <meetvm@gmail.com> wrote:
>> In the article (http://software.intel.com/en-us/articles/enhanced-intel-speedstepr-technology-and-demand-based-switching-on-linux/)
>> the author says that voltage and frequency changes are separated. Does
>> this mean that even though a chip has chip-wide DVFS where the voltage
>> is changed simultaneously across all cores, the frequency of each core
>> can be still changed individually? Kindly let me know your comments.
>
> Dirk is an Intel expert and I am not :)
>
> But, this is what is present at the link you gave:
>
> "Separation between Voltage and Frequency Changes. By stepping voltage
> up and down in small increments separately from frequency changes, the
> processor is able to reduce periods of system unavailability (which
> occur during frequency change). Thus, the system is able to transition
> between voltage and frequency states more often, providing improved
> power/performance balance.
> "
>
> And this probably means voltage/freq can be changed in small steps
> independently to each other.. So that when you change freq you don't
> necessarily change voltage..
>
> eg: You want to go to a high freq..and you need high voltage for it..
> - So increase voltage in small steps first.. so that freq line stays
> stable and processor can work during that time..
> - Now change freq and it may put cpu on idle for some time..
>
> I couldn't make out if it said something about multiple cpus DVFS.

Re: Clarification on the DVFS capabilities

[Viresh Kumar]

On 26 May 2013 05:30, karthik vm <meetvm@gmail.com> wrote:
> Thanks for your insights Viresh. I really appreciate it!!
>
> Basically I wanted to know the DVFS granularity of a multi-core chip.
> i.e I want to know whether every core can separately increase or
> decrease its frequency or all the cores increase or decrease
> simultaneously. I think cpufreq-info command's output "CPUs which need
> to have their frequency coordinated by software" gives the answer. For
> my core2duo processor it says either core 0 or core 1. Hence frequency
> of each of my cores can be changed individually. Experimental results
> also supports it. Please correct me if there is any fallacy in my
> inference.

Whether cores can have separate control of clks or not is decided by
hardware implementation. On ARM normally all cores within a cluster
have common control of clk lines.. On Intel, I am not sure.

Now, the hardware can have interesting capabilities where they can
manage separate clk lines themselves and software doesn't need to
do anything special for them. And so that's what Dirk pointed out
earlier.

Your observation looks correct though.

Re: Clarification on the DVFS capabilities

[karthik vm]

Thanks for your insights Viresh & Dirk. I really appreciate it.

I read from the net that the p-state (Voltage/Frequency) pairs in
Intel processors(e.g Nehalem) cannot be set for individual cores
(http://web.archive.org/web/20130527001342/http://people.cs.pitt.edu/~kirk/cs3150spring2010/ShiminChen.pptx).

As Dirk pointed out, each core may request a p-state but ultimately
all the whole processor's p-state is set to the minimum of the
requested p-states. But in my Core2Duo processor, I see that two cores
are in different frequencies(p-state) and it did not fit into the
explanation above :-(. I think I am missing something.

Regards,
karthik

On Sun, May 26, 2013 at 3:01 AM, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> On 26 May 2013 05:30, karthik vm <meetvm@gmail.com> wrote:
>> Thanks for your insights Viresh. I really appreciate it!!
>>
>> Basically I wanted to know the DVFS granularity of a multi-core chip.
>> i.e I want to know whether every core can separately increase or
>> decrease its frequency or all the cores increase or decrease
>> simultaneously. I think cpufreq-info command's output "CPUs which need
>> to have their frequency coordinated by software" gives the answer. For
>> my core2duo processor it says either core 0 or core 1. Hence frequency
>> of each of my cores can be changed individually. Experimental results
>> also supports it. Please correct me if there is any fallacy in my
>> inference.
>
> Whether cores can have separate control of clks or not is decided by
> hardware implementation. On ARM normally all cores within a cluster
> have common control of clk lines.. On Intel, I am not sure.
>
> Now, the hardware can have interesting capabilities where they can
> manage separate clk lines themselves and software doesn't need to
> do anything special for them. And so that's what Dirk pointed out
> earlier.
>
> Your observation looks correct though.

Re: Clarification on the DVFS capabilities

[Viresh Kumar]

On 27 May 2013 05:50, karthik vm <meetvm@gmail.com> wrote:
> Thanks for your insights Viresh & Dirk. I really appreciate it.
>
> I read from the net that the p-state (Voltage/Frequency) pairs in
> Intel processors(e.g Nehalem) cannot be set for individual cores
> (http://web.archive.org/web/20130527001342/http://people.cs.pitt.edu/~kirk/cs3150spring2010/ShiminChen.pptx).

I don't really know how much we can trust this one..

> As Dirk pointed out, each core may request a p-state but ultimately
> all the whole processor's p-state is set to the minimum of the
> requested p-states. But in my Core2Duo processor, I see that two cores
> are in different frequencies(p-state) and it did not fit into the
> explanation above :-(. I think I am missing something.

How do you see that? cpufreq-info? That can be tricky as the cpufreq
driver might not have exposed this to core.. So, core thinks  cores can
run at separate frequencies but code in driver is taking care to pass
on the minimum of all cores to h/w.

Re: Clarification on the DVFS capabilities

[Dirk Brandewie]

On 05/26/2013 05:20 PM, karthik vm wrote:
> Thanks for your insights Viresh & Dirk. I really appreciate it.
>
> I read from the net that the p-state (Voltage/Frequency) pairs in
> Intel processors(e.g Nehalem) cannot be set for individual cores
> (http://web.archive.org/web/20130527001342/http://people.cs.pitt.edu/~kirk/cs3150spring2010/ShiminChen.pptx).
>
> As Dirk pointed out, each core may request a p-state but ultimately
> all the whole processor's p-state is set to the minimum of the
> requested p-states. But in my Core2Duo processor, I see that two cores
> are in different frequencies(p-state) and it did not fit into the
> explanation above :-(. I think I am missing something.

The requested p-state is being reported which is individually controllable
AFAIK there is no way to get the instantaneous operation frequncy of the package.

You can look at the APERF/MPERF to tell what effective frequency the core ran
at over a sample time but that is the closet you can get to the actual
frequency the core "is" runing at.


>
> Regards,
> karthik
>
> On Sun, May 26, 2013 at 3:01 AM, Viresh Kumar <viresh.kumar@linaro.org> wrote:
>> On 26 May 2013 05:30, karthik vm <meetvm@gmail.com> wrote:
>>> Thanks for your insights Viresh. I really appreciate it!!
>>>
>>> Basically I wanted to know the DVFS granularity of a multi-core chip.
>>> i.e I want to know whether every core can separately increase or
>>> decrease its frequency or all the cores increase or decrease
>>> simultaneously. I think cpufreq-info command's output "CPUs which need
>>> to have their frequency coordinated by software" gives the answer. For
>>> my core2duo processor it says either core 0 or core 1. Hence frequency
>>> of each of my cores can be changed individually. Experimental results
>>> also supports it. Please correct me if there is any fallacy in my
>>> inference.
>>
>> Whether cores can have separate control of clks or not is decided by
>> hardware implementation. On ARM normally all cores within a cluster
>> have common control of clk lines.. On Intel, I am not sure.
>>
>> Now, the hardware can have interesting capabilities where they can
>> manage separate clk lines themselves and software doesn't need to
>> do anything special for them. And so that's what Dirk pointed out
>> earlier.
>>
>> Your observation looks correct though.

Re: Clarification on the DVFS capabilities

[karthik vm]

Thanks for the pointers Dirk & Viresh. They are very helpful.

I went thru few white papers on power management on Sandy Bridge,
Nehalem & Core Duo architectures.

I found that for Sandy Bridge & Nehalem there is a embedded
micro-controller called Power Control Unit(PCU) that accepts the
p-state requests from OS for each core and it decides at what p-state
all the cores(normally 4) should run.

In Core Duo architecture there is a hardware coordinating unit which
accepts the p-state requests from OS for each core and it decides what
p-state both the cores should run based on some thermal limitations. I
hope Core2Duo (my test processor) the successor to Core Duo also works
the same way. Am I right Dirk? because the paper said that "future
implementations may choose to select a different operating point per
core". Thats why I want to confirm.

Hence as Dirk said we never know what the current instantaneous
frequency of each core. The cpufreq stats only give the requested
p-state on each core not their current values. Having said that I
assume that the cpu frequency information from 1) "scaling_cur_freq"
file in cpufreq directory 2) /proc/cpuinfo are also the requested
p-state and not the current values. Kindly correct me if I am wrong.

Thanks for your time,
karthik

On Tue, May 28, 2013 at 11:09 AM, Dirk Brandewie
<dirk.brandewie@gmail.com> wrote:
> On 05/26/2013 05:20 PM, karthik vm wrote:
>>
>> Thanks for your insights Viresh & Dirk. I really appreciate it.
>>
>> I read from the net that the p-state (Voltage/Frequency) pairs in
>> Intel processors(e.g Nehalem) cannot be set for individual cores
>>
>> (http://web.archive.org/web/20130527001342/http://people.cs.pitt.edu/~kirk/cs3150spring2010/ShiminChen.pptx).
>>
>> As Dirk pointed out, each core may request a p-state but ultimately
>> all the whole processor's p-state is set to the minimum of the
>> requested p-states. But in my Core2Duo processor, I see that two cores
>> are in different frequencies(p-state) and it did not fit into the
>> explanation above :-(. I think I am missing something.
>
>
> The requested p-state is being reported which is individually controllable
> AFAIK there is no way to get the instantaneous operation frequncy of the
> package.
>
> You can look at the APERF/MPERF to tell what effective frequency the core
> ran
> at over a sample time but that is the closet you can get to the actual
> frequency the core "is" runing at.
>
>
>
>>
>> Regards,
>> karthik
>>
>> On Sun, May 26, 2013 at 3:01 AM, Viresh Kumar <viresh.kumar@linaro.org>
>> wrote:
>>>
>>> On 26 May 2013 05:30, karthik vm <meetvm@gmail.com> wrote:
>>>>
>>>> Thanks for your insights Viresh. I really appreciate it!!
>>>>
>>>> Basically I wanted to know the DVFS granularity of a multi-core chip.
>>>> i.e I want to know whether every core can separately increase or
>>>> decrease its frequency or all the cores increase or decrease
>>>> simultaneously. I think cpufreq-info command's output "CPUs which need
>>>> to have their frequency coordinated by software" gives the answer. For
>>>> my core2duo processor it says either core 0 or core 1. Hence frequency
>>>> of each of my cores can be changed individually. Experimental results
>>>> also supports it. Please correct me if there is any fallacy in my
>>>> inference.
>>>
>>>
>>> Whether cores can have separate control of clks or not is decided by
>>> hardware implementation. On ARM normally all cores within a cluster
>>> have common control of clk lines.. On Intel, I am not sure.
>>>
>>> Now, the hardware can have interesting capabilities where they can
>>> manage separate clk lines themselves and software doesn't need to
>>> do anything special for them. And so that's what Dirk pointed out
>>> earlier.
>>>
>>> Your observation looks correct though.
>
>

Re: Clarification on the DVFS capabilities

[Dirk Brandewie]

On 05/29/2013 09:33 AM, karthik vm wrote:
> Thanks for the pointers Dirk & Viresh. They are very helpful.
>
> I went thru few white papers on power management on Sandy Bridge,
> Nehalem & Core Duo architectures.
>
> I found that for Sandy Bridge & Nehalem there is a embedded
> micro-controller called Power Control Unit(PCU) that accepts the
> p-state requests from OS for each core and it decides at what p-state
> all the cores(normally 4) should run.
>
> In Core Duo architecture there is a hardware coordinating unit which
> accepts the p-state requests from OS for each core and it decides what
> p-state both the cores should run based on some thermal limitations. I
> hope Core2Duo (my test processor) the successor to Core Duo also works
> the same way. Am I right Dirk?

AFAIK yes but I haven't looked at the specific docs for your processor.
The SDM 
http://www.intel.com/content/www/us/en/processors/architectures-software-developer-manuals.html 
has the authoritative info.

> because the paper said that "future
> implementations may choose to select a different operating point per
> core". Thats why I want to confirm.
>
> Hence as Dirk said we never know what the current instantaneous
> frequency of each core. The cpufreq stats only give the requested
> p-state on each core not their current values. Having said that I
> assume that the cpu frequency information from 1) "scaling_cur_freq"
> file in cpufreq directory 2) /proc/cpuinfo are also the requested
> p-state and not the current values. Kindly correct me if I am wrong.
>

If you are using acpi-cpufreq scaling driver and ondemand governor you
are correct.

The intel_pstate driver returns the frequency that the core ran at during
the most recent sample time.

> Thanks for your time,
> karthik
>
> On Tue, May 28, 2013 at 11:09 AM, Dirk Brandewie
> <dirk.brandewie@gmail.com> wrote:
>> On 05/26/2013 05:20 PM, karthik vm wrote:
>>>
>>> Thanks for your insights Viresh & Dirk. I really appreciate it.
>>>
>>> I read from the net that the p-state (Voltage/Frequency) pairs in
>>> Intel processors(e.g Nehalem) cannot be set for individual cores
>>>
>>> (http://web.archive.org/web/20130527001342/http://people.cs.pitt.edu/~kirk/cs3150spring2010/ShiminChen.pptx).
>>>
>>> As Dirk pointed out, each core may request a p-state but ultimately
>>> all the whole processor's p-state is set to the minimum of the
>>> requested p-states. But in my Core2Duo processor, I see that two cores
>>> are in different frequencies(p-state) and it did not fit into the
>>> explanation above :-(. I think I am missing something.
>>
>>
>> The requested p-state is being reported which is individually controllable
>> AFAIK there is no way to get the instantaneous operation frequncy of the
>> package.
>>
>> You can look at the APERF/MPERF to tell what effective frequency the core
>> ran
>> at over a sample time but that is the closet you can get to the actual
>> frequency the core "is" runing at.
>>
>>
>>
>>>
>>> Regards,
>>> karthik
>>>
>>> On Sun, May 26, 2013 at 3:01 AM, Viresh Kumar <viresh.kumar@linaro.org>
>>> wrote:
>>>>
>>>> On 26 May 2013 05:30, karthik vm <meetvm@gmail.com> wrote:
>>>>>
>>>>> Thanks for your insights Viresh. I really appreciate it!!
>>>>>
>>>>> Basically I wanted to know the DVFS granularity of a multi-core chip.
>>>>> i.e I want to know whether every core can separately increase or
>>>>> decrease its frequency or all the cores increase or decrease
>>>>> simultaneously. I think cpufreq-info command's output "CPUs which need
>>>>> to have their frequency coordinated by software" gives the answer. For
>>>>> my core2duo processor it says either core 0 or core 1. Hence frequency
>>>>> of each of my cores can be changed individually. Experimental results
>>>>> also supports it. Please correct me if there is any fallacy in my
>>>>> inference.
>>>>
>>>>
>>>> Whether cores can have separate control of clks or not is decided by
>>>> hardware implementation. On ARM normally all cores within a cluster
>>>> have common control of clk lines.. On Intel, I am not sure.
>>>>
>>>> Now, the hardware can have interesting capabilities where they can
>>>> manage separate clk lines themselves and software doesn't need to
>>>> do anything special for them. And so that's what Dirk pointed out
>>>> earlier.
>>>>
>>>> Your observation looks correct though.
>>
>>

Re: Clarification on the DVFS capabilities

[karthik vm]

Thanks for the info Dirk.

The Intel Architecture Software Developer Manual, Chapter 14 Power &
Thermal Management gave pointers to check for the availability of
APERF & MPERF MSRs using the CPUID instruction. When I ran CPUID &
checked the results in my Core2Duo processor it showed that my
processor has both APERF & MPERF MSRs. Hence this also shows that
similar to Core Duo architecture, Core2Duo also has a hardware
coordinating unit which coordinates the P-State of the cores. Thanks a
lot Drik & Viresh for the good pointers.

Regards,
karthik

On Wed, May 29, 2013 at 12:53 PM, Dirk Brandewie
<dirk.brandewie@gmail.com> wrote:
> On 05/29/2013 09:33 AM, karthik vm wrote:
>>
>> Thanks for the pointers Dirk & Viresh. They are very helpful.
>>
>> I went thru few white papers on power management on Sandy Bridge,
>> Nehalem & Core Duo architectures.
>>
>> I found that for Sandy Bridge & Nehalem there is a embedded
>> micro-controller called Power Control Unit(PCU) that accepts the
>> p-state requests from OS for each core and it decides at what p-state
>> all the cores(normally 4) should run.
>>
>> In Core Duo architecture there is a hardware coordinating unit which
>> accepts the p-state requests from OS for each core and it decides what
>> p-state both the cores should run based on some thermal limitations. I
>> hope Core2Duo (my test processor) the successor to Core Duo also works
>> the same way. Am I right Dirk?
>
>
> AFAIK yes but I haven't looked at the specific docs for your processor.
> The SDM
> http://www.intel.com/content/www/us/en/processors/architectures-software-developer-manuals.html
> has the authoritative info.
>
>
>> because the paper said that "future
>> implementations may choose to select a different operating point per
>> core". Thats why I want to confirm.
>>
>> Hence as Dirk said we never know what the current instantaneous
>> frequency of each core. The cpufreq stats only give the requested
>> p-state on each core not their current values. Having said that I
>> assume that the cpu frequency information from 1) "scaling_cur_freq"
>> file in cpufreq directory 2) /proc/cpuinfo are also the requested
>> p-state and not the current values. Kindly correct me if I am wrong.
>>
>
> If you are using acpi-cpufreq scaling driver and ondemand governor you
> are correct.
>
> The intel_pstate driver returns the frequency that the core ran at during
> the most recent sample time.
>
>
>> Thanks for your time,
>> karthik
>>
>> On Tue, May 28, 2013 at 11:09 AM, Dirk Brandewie
>> <dirk.brandewie@gmail.com> wrote:
>>>
>>> On 05/26/2013 05:20 PM, karthik vm wrote:
>>>>
>>>>
>>>> Thanks for your insights Viresh & Dirk. I really appreciate it.
>>>>
>>>> I read from the net that the p-state (Voltage/Frequency) pairs in
>>>> Intel processors(e.g Nehalem) cannot be set for individual cores
>>>>
>>>>
>>>> (http://web.archive.org/web/20130527001342/http://people.cs.pitt.edu/~kirk/cs3150spring2010/ShiminChen.pptx).
>>>>
>>>> As Dirk pointed out, each core may request a p-state but ultimately
>>>> all the whole processor's p-state is set to the minimum of the
>>>> requested p-states. But in my Core2Duo processor, I see that two cores
>>>> are in different frequencies(p-state) and it did not fit into the
>>>> explanation above :-(. I think I am missing something.
>>>
>>>
>>>
>>> The requested p-state is being reported which is individually
>>> controllable
>>> AFAIK there is no way to get the instantaneous operation frequncy of the
>>> package.
>>>
>>> You can look at the APERF/MPERF to tell what effective frequency the core
>>> ran
>>> at over a sample time but that is the closet you can get to the actual
>>> frequency the core "is" runing at.
>>>
>>>
>>>
>>>>
>>>> Regards,
>>>> karthik
>>>>
>>>> On Sun, May 26, 2013 at 3:01 AM, Viresh Kumar <viresh.kumar@linaro.org>
>>>> wrote:
>>>>>
>>>>>
>>>>> On 26 May 2013 05:30, karthik vm <meetvm@gmail.com> wrote:
>>>>>>
>>>>>>
>>>>>> Thanks for your insights Viresh. I really appreciate it!!
>>>>>>
>>>>>> Basically I wanted to know the DVFS granularity of a multi-core chip.
>>>>>> i.e I want to know whether every core can separately increase or
>>>>>> decrease its frequency or all the cores increase or decrease
>>>>>> simultaneously. I think cpufreq-info command's output "CPUs which need
>>>>>> to have their frequency coordinated by software" gives the answer. For
>>>>>> my core2duo processor it says either core 0 or core 1. Hence frequency
>>>>>> of each of my cores can be changed individually. Experimental results
>>>>>> also supports it. Please correct me if there is any fallacy in my
>>>>>> inference.
>>>>>
>>>>>
>>>>>
>>>>> Whether cores can have separate control of clks or not is decided by
>>>>> hardware implementation. On ARM normally all cores within a cluster
>>>>> have common control of clk lines.. On Intel, I am not sure.
>>>>>
>>>>> Now, the hardware can have interesting capabilities where they can
>>>>> manage separate clk lines themselves and software doesn't need to
>>>>> do anything special for them. And so that's what Dirk pointed out
>>>>> earlier.
>>>>>
>>>>> Your observation looks correct though.
>>>
>>>
>>>
>