5-STABLE cpufreq hotter than est from ports

[Kevin Oberman]

> Date: Wed, 10 Aug 2005 23:13:11 -0700
> From: Nate Lawson <nate at root.org>
> 
> Kevin Oberman wrote:
> >>Date: Tue, 9 Aug 2005 11:35:29 +0200
> >>From: Bruno Ducrot <ducrot at poupinou.org>
> >>Sender: owner-freebsd-stable at freebsd.org
> >>
> >>On Tue, Aug 02, 2005 at 12:22:02AM +0200, Tijl Coosemans wrote:
> >>
> >>>A couple days ago I updated my system and was excited to see cpufreq
> >>>and powerd in 5-stable. Since then however I noticed that my laptop
> >>>temperature is about 5°C higher than with est and estctrl. I found that
> >>>cpufreq when setting 200MHz for example set the absolute frequency to
> >>>1600MHz (max for this laptop) and the relative frequency (p4tcc) to
> >>>12.5% instead of using a more power conserving setting like 800MHz/25%.
> >>>
> >>>The problem is that cpufreq_expand_set() (sys/kern/kern_cpu.c)
> >>>traverses freq levels from high to low when adding relative levels and
> >>>skips duplicates. When it wants to add 800MHz/25% it sees this setting
> >>>as a duplicate of 1600MHz/12.5% it has found before. This can be fixed
> >>>by letting cpufreq_expand_set() traverse freq levels in reverse order
> >>>(and still skipping duplicates). Then each frequency level has the
> >>>lowest possible absolute setting. This is a one line change in
> >>>sys/kern/kern_cpu.c (line 653).
> >>
> >>It's a well known bug.  Someday I think I will have enough time to fix
> >>that one if Nate don't bite me.
> > 
> > I have been running with Tijl's patch set for several days with great
> > results. Testing has shown that the patches resolve both issues and I
> > now see only 11 CPU speeds, all of those below the lower CPU clock speed
> > are at that lower speed. Thus far I have seen no negative issues. The
> > temperature of my system is noticeably cooler when not running something
> > that is compute intensive.
> 
> I'm working on reviewing and perhaps rewriting some of the patches. 
> They may work fine but there are some subtle issues, for instance, with 
> future systems that support more than one relative driver.  The goals 
> are correct but the implementation needs a little work.

No problem. I was just confirming that the patch was working well on a
system using TCC and SpeedStep. I have only given the actual patch a
quick scan to confirm that it did pretty much what was claimed.

"More than one relative driver"? I had never considered that, but I can
see the possibility. Guess that's why Bruno and you are doing this and
I'm not. (Well, the fact that I write ugly code and have never read all
of the ACPI spec has something to do with it, too.)
-- 
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