5-STABLE cpufreq hotter than est from ports

Tijl Coosemans tijl at ulyssis.org
Mon Aug 8 14:18:23 GMT 2005


Kevin,

Thanks for your reply. I was beginning to think I sent my mail to the 
wrong list. I've subscribed to freebsd-acpi@ now. For reference, the 
issues (+patch) discussed are available at:

http://lists.freebsd.org/pipermail/freebsd-stable/2005-August/017535.html
http://lists.freebsd.org/pipermail/freebsd-stable/2005-August/017536.html

> 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! 

In my experience throttling doesn't really gain that much. There's 
almost no difference between running at 600MHz/100% and 600MHz/12.5%, 
except that it is 8 times slower, so I've set debug.cpufreq.lowest to 
400 to limit the performance drop.

I've also slightly modified powerd to not jump to the maximum frequency, 
but to step up one level at a time to save energy. I've been thinking, 
since throttling doesn't gain much, it might be better for powerd to 
use only absolute settings when stepping up, but that would require an 
extra sysctl entry (dev.cpu.0.freq_abs or something).

All this together with the patch above gives me a good desktop 
experience. It's not too slow and it doesn't consume much power either. 
Of course, other users might prefer different power profiles.

> 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?

Currently, acpi_throttle (driver) doesn't attach when it finds p4tcc0 
(device), but p4tcc (driver) always attaches even if acpi_throttle0 
(device) is present. As I understand things, both do exactly the same 
(but in a different way), so they shouldn't both be enabled at the same 
time.

You can get in this situation by not loading cpufreq.ko through 
loader.conf (so acpi_throttle attaches) and then kldload it later. If 
p4tcc is prefered, I suppose it should find acpi_throttle0 and detach 
it (or maybe acpi_throttle should become part of cpufreq.ko).

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

I've found references in the following files. There may be more of 
course.

sys/conf/files.i386 (line 258)
sys/conf/options.i386 (line 56)
sys/i386/conf/NOTES (line 133 + line 215).
sys/i386/i386/p4tcc.c (can be removed?)


More information about the freebsd-acpi mailing list