[patch] enhance powerd(8) to handle max temperature

Hajimu UMEMOTO ume at freebsd.org
Tue Jul 31 01:21:36 UTC 2007


>>>>> On Mon, 30 Jul 2007 23:31:33 +0200
>>>>> Pietro Cerutti <gahr at gahr.ch> said:

gahr> I can't test it, since I can't use passive cooling, but how do not these
gahr> two systems interfere with each other wrt setting the CPU frequency?
gahr> What if, for example, my CPU temperature rises above _PSV but the CPU
gahr> usage drops below 65%?

Do you mean that your hw.acpi.thermal.tz0._PSV has reasonable value?
If so, perhaps, your ACPI BIOS is broken, and _TC1, _TC2 and _TSP are
not defined correctly.  Please show me the output of `sysctl hw.acpi'
and `acpidump -dt'.

gahr> In this case, the CPU frequency should be increased according to
gahr> powerd's algorithm and should be decreased according to passive
gahr> cooling's algorithm.

gahr> Wouldn't it be better to have one subsystem deal with both usage and
gahr> temperature in order to decide which is the best next frequency to be set?

No, we have a priority to control a cpufreq in our kernel, to deal
with conflict between kernel and userland.  Controlling cpufreq within
our kernel is considered as high proirity.  So, during our kernel is
controlling a cpufreq, we cannot change cpufreq from userland.  And,
our kernel releasing the control, a cpufreq is back to the value
before our kernel changed it.

gahr> My patch is really just a first draft that I wrote in order to have
gahr> feedbacks on the general idea to implement a temperature controlling
gahr> system inside powerd, and doesn't implement hysteresis as you noted, and
gahr> your feedback is that it's not a good idea, which I respect.

It is rather backward, IMHO.  I did implement a passive cooling
feature as an enhancement of powerd(8) like you did, during initial
phases.  Then, I implemented it in our kernel as a result.


Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
ume at mahoroba.org  ume@{,jp.}FreeBSD.org

More information about the freebsd-acpi mailing list