Re: Clarification on the DVFS capabilities

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxx> wrote:
On 26 May 2013 05:30, karthik vm <meetvm@xxxxxxxxx> 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.

--
To unsubscribe from this list: send the line "unsubscribe cpufreq" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Devel]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Forum]     [Linux SCSI]

  Powered by Linux