5-STABLE cpufreq hotter than est from ports

[Bruno Ducrot]

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.

> With this patch temperature is almost as low as with est again (only
> 1°C hotter). However, there are still such levels like 1400/12.5
> (175MHz) which are lower than let's say 600/37.5 (225MHz), but consume
> a lot more power. On my laptop this problem doesn't really occur
> because of the way powerd works, only the absolute levels 1600, 800 and
> 600 are ever used. I can imagine somebody with a 1700MHz cpu not being
> so lucky though. So, I've worked out a patch (attached) that makes sure
> that a lower frequency level has at most the same absolute setting
> (preferably less of course). This eliminates quite a few levels so
> somebody with a better knowledge of cpufreq should check if this patch
> really does something good. This is the first time I've taken a look at
> FreeBSD source code by the way.

It's in my todo list in a so long time that I must admit I must be
blamed to have not fixed that already.

> Also, somewhat related, the p4tcc driver doesn't recognise
> acpi_throttle, which means that when you load the cpufreq module after
> booting, the freq levels are messed up. I'm not sure what the best
> solution for this is. Let p4tcc detect acpi_throttle and don't attach
> if it's present (like acpi_throttle does now if it finds p4tcc) or
> detach it before attaching? Or maybe p4tcc and acpi_throttle should be
> merged into one driver?
> 
> Finally, is the kernel config option CPU_ENABLE_TCC still relevant?
> Because it's still listed in NOTES.

Right.  I forgot to kill that option.

-- 
Bruno Ducrot

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.