cpufreq broken on core2duo

Mon Jun 9 17:45:17 UTC 2008

> Date: Sun, 8 Jun 2008 22:30:35 -0700
> From: Jeremy Chadwick <koitsu at FreeBSD.org>
> 
> On Sun, Jun 08, 2008 at 10:13:43PM -0700, Kevin Oberman wrote:
> > > Date: Sat, 7 Jun 2008 09:48:12 -0700
> > > From: Jeremy Chadwick <koitsu at FreeBSD.org>
> > > Sender: owner-freebsd-stable at freebsd.org
> > > 
> > > On Sat, Jun 07, 2008 at 05:51:38PM +0300, Evren Yurtesen wrote:
> > > > By the way, there is another thing I am wondering about. If I enable HTT 
> > > > and Intel Enhanced SpeedStep in bios on a 3.00GHZ p4 CPU I see:
> > > >
> > > > cpu0: <ACPI CPU> on acpi0
> > > > acpi_perf0: <ACPI CPU Frequency Control> on cpu0
> > > > p4tcc0: <CPU Frequency Thermal Control> on cpu0
> > > > cpu1: <ACPI CPU> on acpi0
> > > > est1: <Enhanced SpeedStep Frequency Control> on cpu1
> > > > est: CPU supports Enhanced Speedstep, but is not recognized.
> > > > est: cpu_vendor GenuineIntel, msr f2700000f27
> > > > device_attach: est1 attach returned 6
> > > > p4tcc1: <CPU Frequency Thermal Control> on cpu1
> > > >
> > > > dev.cpu.0.freq_levels: 1500/27000 1312/23625 1200/13000 1050/11375 900/9750 
> > > > 750/8125 600/6500 450/4875 300/3250 150/1625
> > > > dev.acpi_perf.0.freq_settings: 1500/27000 1200/13000
> > > > dev.cpufreq.0.%driver: cpufreq
> > > > dev.cpufreq.0.%parent: cpu0
> > > > dev.cpufreq.1.%driver: cpufreq
> > > > dev.cpufreq.1.%parent: cpu1
> > > > dev.p4tcc.0.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1 
> > > > 2500/-1 1250/-1
> > > > dev.p4tcc.1.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1 
> > > > 2500/-1 1250/-1
> > > >
> > > > and it does not allow me to set the freq. of the cpu.
> > > 
> > > How are you setting the frequency?  Are you using powerd?  You do not
> > > have to enable SpeedStep in your BIOS to achieve throttling CPU clock
> > > speed.  In fact, I would highly recommend leaving EIST/SpeedStep in the
> > > BIOS *disabled*, and let powerd adjust the clock frequency via ACPI.
> > 
> > I must strongly recommend against this. EST is MUCH more efficient on
> > its control of power use than simple throttling. So much so that on my
> > systems that support EST, I remove cpufreq from the kernel. (In all
> > cases, throttling means either simple throttling or throttling by using
> > TCC.) 
> 
> The reality of the situation is that users cannot use EIST reliably on
> FreeBSD.  I cannot imagine removing cpufreq would solve the "runtime
> went backwards" issue.  The EIST problem needs to be fixed.  If the
> folks who work on it do not have present-day hardware (C2Ds, etc.), I
> will be more than happy to purchase them whatever they need.
> 
> > I did quite a bit of testing on power management a year or so ago and
> > found that throttling was of value only for controlling CPU temperature.
> > For real power management, EST works far better as it adjust frequency
> > (actual clock rate) and CPU voltage while throttling just stops and
> > starts the clock without changing its actual frequency. (This came as a
> > surprise to me about 5 years ago when I first discovered it.)
> 
> As far as I know, the ACPI frequency toggling does in fact adjust the
> CPU clock rate -- because the values in dev.cpu.0.freq_levels are
> defined by the ACPI configuration on the machine.

It claims to adjust clock speed, but it actually simply "skips"
cycles. The system clocks at its standard rate or that provided by other
power management tools. Since throttling (whether done by the external
throttling or TCC) will provide 8 "frequencies". If SpeedStep, EST, or
PowerNow is available, it will show 8 times the number of "true"
frequencies provided by any of those. (Actually, on my system EST
provides 16 "frequencies" of which 4 are actual changes in the clock
and the others are from 4 voltages it uses. 4**2 = 16.

If you see exactly eight "frequencies" with cpufreq, you have no "true"
frequency adjustment.

> I'd confirm this, but looking at the kernel code doesn't help -- I
> cannot find the definition of the CPUFREQ_LEVELS function or macro.
> 
> > At idle, throttling does exactly nothing. EST reduces voltage on the
> > CPU and saves power even when idle. At full CPU load, throttling reduces
> > performance and power consumption equally. EST beats it by a slim
> > margin.
> 
> I thought the power-saving modes of the CPU (C1E/C2E/C3E/C4E) could be
> used *without* enabling EIST.  I don't think FreeBSD has kernel or
> userland support utilities to enable/disable CPU-level features.
> Something like RMClock for Windows would be quite useful.  (If you have
> the opportunity to run it, do so; you'll see what I mean, re: all the
> features being toggleable individually).

Yes, C-states are not tied to EST or any "frequency-like" things. And
they are a really significant factor in power saving. I'll have to look
at RMClock. I am not familiar with it. (I don't normally use Windows,
but I can boot it on my laptop.)

> > The big win is at moderate load. Throttling can result is very poor
> > results for aps like video and music which will place a continuous load
> > on the system, but only 20-60% (in the case of my test system). It
> > tended to make the system seem sluggish. EST does a much better job in
> > this case as it lowers CP voltage and clock rate to maximize performance
> > while minimizing power.
> >
> > If your only concern is keeping the system cool, throttling will do the
> > job, but if you want efficient power utilization, use EST if possible.
> 
> In the case est does not attach (e.g. no EIST support enabled in
> FreeBSD), the throttling method resorts to simply suspending the system,
> then yes I completely agree -- EIST is significantly better than that.

If you have no better method than throttling, you have to go with it,
but it's way to primitive to be a really big help.

FWIW, on my ThinkPad (uni-processor), with no cpufreq in the system, I
see:
dev.cpu.0.freq_levels: 2000/27000 1750/23625 1600/22600 1400/19775 1333/19666 1166/17207 1066/16733 932/14641 800/13800 700/12075 600/10350 500/8625 400/6900 300/5175 200/3450 100/1725

It is running EST and P4TCC is explicitly disabled in loader.conf.

Oh, and my testing showed that TCC did a slightly better job than simple
throttling, though they do about the same thing, so the difference is
probably not significant. With the current code, if P4TCC is available,
it will be used in preference to throttling. Both will never be used
together. (That was a good way to lock up your system during the time
both were used.)
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: oberman at es.net			Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 224 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080609/f01723ae/attachment.pgp