Re: Clarification on the DVFS capabilities

[Dirk Brandewie <dirk.brandewie@gmail.com>]

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