5-STABLE cpufreq hotter than est from ports

[Kevin Oberman]

> From: Tijl Coosemans <tijl at ulyssis.org>
> Date: Tue, 2 Aug 2005 00:22:02 +0200
> Sender: owner-freebsd-stable at freebsd.org
> 
> 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.

Tijl,

Thanks so much for doing this work.

I had done exactly the same sort of testing and found the same issues,
but ave not had time to track down the kernel changes required to fix
them. And I DO see both problems.

I have a P4m with ICHSS and P4TCC and I do hit both the problem of the
wrong mode being selected when there is a tie for performance level and
the case of lower performance resulting in higher power consumption. You
can see the results of my testing in messages to freebsd-acpi@ archives.
I have been wanting to write some patches to fix the problems, but have
simply not had time, so these patches look great!

I run -current on my laptop, so I may have to make adjustments to your
patches, but I m sure that you have saved me a lot of time in any case.

Could you please be sure to copy ducrot@ with these messages?  He and
Nate are the primary author of the code involved and can get
it into the system. In the future you should probably send these reports
to freebsd-acpi at . That's where most of the work on this sort of thing is
done. (Yes, I realize that this is not technically ACPI stuff, but it is
all tied to ACPI capabilities.)

To take a stab at your questions:
First, if P4TCC is available, it should be used and CPU throttling should
be disabled. This is because P4TCC does better than CPU throttle, but
really does the exact same thing. The results of my testing of P4TCC
vs. throttling are also in the archives of freebsd-acpi at .

I have not seen any problem with this. Could you describe exactly whet
behavior you are seeing?

I am pretty sure that 'option CPU_TCC_ENABLE' is obsolete. It's gone from
V6 and current. I suspect that it was missed when the CPU power
management stuff was MFCed to V5. Please drop freebsd-acpi@ a note so
this can be fixed.

finally, you might want to subscribe to freebsd-acpi at . It's fairly low
volume, but covers pretty much all of the work being done in this
area. (By fairly low, I mean it averages around 3 or 4 messages a day.

Again, thanks for the patches!
-- 
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