Li, Aubrey wrote: > Mark.Haywood wrote: > > >> Li, Aubrey wrote: >> >>> Mark.Haywood wrote: >>> >>> >>> >>>> Li, Aubrey wrote: >>>> >>>> >>>>> Firstly, many thanks to report this bug, :-) >>>>> >>>>> Before we setup powertop bug track system on >>>>> defect.opensolaris.org, can we report bug to the mailing list >>>>> first? >>>>> >>>>> my comments about this bug: >>>>> >>>>> This is a very good raise-up, really. But I think it'd better to >>>>> place this bug into Todo list. Currently kernel doesn't support any >>>>> mechanism to obtain the frequency in the "turbo mode". So, powertop >>>>> can't report any related info. Actually hardware feedback machanism >>>>> exists on the processor, We need to enable it. >>>>> >>>>> >>>>> >>>> It is true that the APERF/MPERF hardware feedback mechanism >>>> can help to >>>> identify that a processor has been in "turbo mode". But unless I'm >>>> mistaken there is no guarantee that when the processor is in Turbo >>>> Mode that APERF/MPERF will catch it. Among other things, it would >>>> depend upon your polling interval - which currently is pretty long. >>>> >>>> >>> Can't we assume the processor is in turbo mode when we are in >>> P0 = (market frequency) + 1Mhz? >>> >>> >> I don't think that the processor being at P0 guarantees that it is in >> turbo mode. It means that the processor should operate no lower than >> market frequency and if the circumstances present themselves, then the >> hardware might overclock the processor for some amount of time. >> >> > When kernel boot, we know wether the platform support turbo mode or not. > I happened to have a box support turbo mode. > > when turbo mode is enabled, supported frequency is > 800Mhz:1600Mhz:2400Mhz:2401Mhz, > > and when turbo mode is disabled, supported frequency is > 800Mhz:1600Mhz:2400Mhz. > > So, in turbo mode should be > 1). turbo mode is supported > 2). processor is in P0 > 3). P0 > marked frequency. >
Sorry, I don't understand what you mean above unless you are trying to say that we know that we are in turbo mode when the frequency (which I assume we'd try to figure out using APERF/MPERF) would be greater than the P1 reported frequency? But again, my point was that unless you happen to poll during the right time, the processor might have been in turbo mode and left it and you didn't catch it ... unless you are going to special case entering and leaving P0? > >>>> What exactly would powertop report about 'turbo mode'? Amount of >>>> time spent in "turbo mode"? I think a metric like that is bound to >>>> be incorrect given the current hardware support isn't it? >>>> >>>> >>> If I understand correctly, the bug reporter want to know the average >>> frequency in turbo mode(P0) in a sampling period, if hardware >>> support it. >>> >>> >> This doesn't make much sense to me. A processor is likely (though >> maybe not with the current Solaris implementation), to switch in and >> out of P0 >> many times during a (powertop defined?) polling period. >> >> > It's doable I think. we can calculate the APERF difference and MPERF > difference between in and out P0. then we will have a ratio by the two > difference. so we can know the average frequency You mean that we'd modify the P-state handling logic to special case entering and leaving P0 to keep some running tally? To what end? Let's say that during the polling period we enter and leave P0 5 times and therefore compute the APERF/MPERF ratio 5 times What do we do at the end of the polling period? Do we sum those ratios and divide by 5? What good is this information? It seems to me that we are really stretching things to try to justify providing some turbo mode statistic. BTW, I assume that a processor at P0 can go into C1E and so the APERF/MPERF will not really give an accurate frequency reading of the processor while at C0? Mark
