Mark.Haywood at Sun.COM wrote: > 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?
not poll in the kernel, let's do this by dtrace probe and check in the powertop. >> >>>>> 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. Again, let's do this by the dtrace probe. > > 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 hmm, this is a problem. Let me check if we can exclude C1 by dtrace probe. in all, this is a bug/feature request reported, for me it's worth to support. What do you think? :) Thanks, -Aubrey
