[RFC] Patch to enable temperature ceiling in powerd

[Ian Smith]

On Thu, 7 Feb 2008, Nate Lawson wrote:
 > Kevin Oberman wrote:
 > >> From: "Alexandre \"Sunny\" Kovalenko" <alex.kovalenko at verizon.net>
 > >>
 > >> On Fri, 2008-02-08 at 00:50 +0900, Hajimu UMEMOTO wrote:
 > >>>>>>>> On Wed, 30 Jan 2008 17:56:19 -0500
 > >>>>>>>> "Alexandre \"Sunny\" Kovalenko" <alex.kovalenko at verizon.net> said:
 > >>> alex.kovalenko> Some time ago I have put together patch for powerd, which allows user to
 > >>> alex.kovalenko> specify the temperature threshold at which powerd will lower CPU
 > >>> alex.kovalenko> frequency no matter what the load was at the time. I recently had to
 > >>> alex.kovalenko> adapt it to the 7.0-PRERELEASE for someone with the overheating laptop,
 > >>> alex.kovalenko> which got me to think that it might be useful for someone else yet.
 > >>>
 > >>> alex.kovalenko> Basic idea is fairly simple -- check temperature in TZ0 and, if it has
 > >>> alex.kovalenko> reached certain value, either override frequency with the lowest
 > >>> alex.kovalenko> available (in the case of 'max' setting) or change idle time to 100% and
 > >>> alex.kovalenko> let adaptive algorithm decrease frequency gradually.
 > >>>
 > >>> alex.kovalenko> I imagine it also could be poor man's substitute for the low noise
 > >>> alex.kovalenko> acoustic policy ;)
 > >>>
 > >>> alex.kovalenko> If there is an interest, I will go ahead and submit a PR, otherwise it
 > >>> alex.kovalenko> will live in the mail archives for someone to find. Any comments,
 > >>> alex.kovalenko> suggestions or criticisms are welcome.
 > >>>
 > >>> alex.kovalenko> Temperature threshold (in Celsius) could be set by means of '-T' command
 > >>> alex.kovalenko> line option (as in '-T 60').
 > >>>
 > >>> Our kernel has passive cooling feature, already.  Is it not enough for
 > >>> you?
 > >> I must have missed it somehow, if you could, please, point me in the
 > >> right direction I will really appreciate it.
 > > 
 > > When the temperature reaches hw.acpi.thermal.tz0._PSV, the system will
 > > slow down until the CPU drops to a level below the _PSV value. The
 > > operation, if enabled, is under the control of BIOS (and/or the EC) and
 > > typically runs with substantial hysteresis, but is usually adequate for
 > > keeping the CPU temperature to a safe point.

Doesn't ACPI take this control from BIOS, using cpufreq and _thermal? 

 > > My Pentium-M 2GHz has a value of 94.5C for _PSV. This may seem very
 > > high, but the maximum "safe" operating temperature for the CPU is 100C,
 > > so it is designed for pretty high temperatures. Quiescent temperature
 > > runs about 51C and, during a CPU intensive operation such as a big build
 > > (e.g. make -j2 buildworld) will rise to near 80C. 
 > > 
 > > Before I blew two years of dust out of the heat sinks, I was seeing
 > > about 60C quiescent and about 95 during CPU intensive operations.
 > > Passive cooling was kicking in then and the temperature never went
 > > higher (although the build took longer).
 > 
 > You can override the _PSV value by setting:
 > hw.acpi.thermal.user_override=1
 > 
 > Then:
 > hw.acpi.thermal.tz0._PSV=70C
 > 
 > This will maintain a lower temperature.  Note that user_override is 
 > potentially a bit dangerous because there is no sanity checking of the 
 > value you set.

Assuming passive cooling on tz0 is enabled and working for machine x,
acpi_thermal's acpi_tz_cooling_thread saves current freq then uses the
enabled cpufreq driver/s (eg est + p4tcc or acpi_perf ..) to reduce freq
according to temperature differential until temp < _PSV, then restores
the previously saved cpu freq - if I'm reading that right? 

Meanwhile powerd, every polling interval default .5s, if in max mode or
adaptive mode under load, is trying to increase freq every time, failing
and emitting warnings, no?

Or maybe powerd is reducing freq if (now) idle(r), which I guess should
succeed, perhaps without confusing acpi_tz_cooling_thread's adjustments?

So, wondering how powerd might learn of and defer to thermal tinkering?

Cheers, Ian  (still trying to fit pieces of the ACPI jigsaw puzzle ..)