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