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