From: Dirk Brandewie <dirk.brandewie@gmail.com>
To: karthik vm <meetvm@gmail.com>
Cc: Viresh Kumar <viresh.kumar@linaro.org>,
cpufreq <cpufreq@vger.kernel.org>
Subject: Re: Clarification on the DVFS capabilities
Date: Tue, 28 May 2013 08:09:15 -0700 [thread overview]
Message-ID: <51A4C89B.8090502@intel.com> (raw)
In-Reply-To: <CAOuKo4k+LNz4Ff5N+VJ8k-_TtRwV+9nWXwXz-Jsi00sUEvhA0A@mail.gmail.com>
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.
next prev parent reply other threads:[~2013-05-28 15:09 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-21 16:18 Clarification on the DVFS capabilities karthik vm
2013-05-22 4:08 ` Viresh Kumar
2013-05-22 16:28 ` karthik vm
2013-05-22 16:46 ` Dirk Brandewie
2013-05-23 16:26 ` karthik vm
2013-05-23 10:12 ` Viresh Kumar
2013-05-23 16:51 ` karthik vm
2013-05-24 5:24 ` Viresh Kumar
2013-05-26 0:00 ` karthik vm
2013-05-26 7:01 ` Viresh Kumar
2013-05-27 0:20 ` karthik vm
2013-05-27 4:07 ` Viresh Kumar
2013-05-28 15:09 ` Dirk Brandewie [this message]
2013-05-29 16:33 ` karthik vm
2013-05-29 16:53 ` Dirk Brandewie
2013-06-03 0:37 ` karthik vm
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=51A4C89B.8090502@intel.com \
--to=dirk.brandewie@gmail.com \
--cc=cpufreq@vger.kernel.org \
--cc=meetvm@gmail.com \
--cc=viresh.kumar@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.