5-STABLE cpufreq hotter than est from ports

[Tijl Coosemans]

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).

--- sys/kern/kern_cpu.c.orig    Mon Aug  1 14:42:26 2005
+++ sys/kern/kern_cpu.c Mon Aug  1 15:17:55 2005
@@ -650,7 +650,7 @@

        CF_MTX_ASSERT(&sc->lock);

-       TAILQ_FOREACH(search, &sc->all_levels, link) {
+       TAILQ_FOREACH_REVERSE(search, &sc->all_levels, cf_level_lst, link) {
                /* Skip this level if we've already modified it. */
                for (i = 0; i < search->rel_count; i++) {
                        if (search->rel_set[i].dev == set_arr->sets[0].dev)

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.

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.