Re: Possible CPUFreq governor

[Mark Bidewell <mark.bidewell@alumni.clemson.edu>]

Bruno Ducrot wrote:

>On Wed, Apr 27, 2005 at 08:30:45AM -0400, Mark Bidewell wrote:
>  
>
>>You are correct, The primary differences are that
>>1)  the clock modulation only cuts in after dangerous temperatures have 
>>been detected.  This code prevents those high temperatures.
>>2)  This code uses the OS Scheduler to make targeted performance cuts on 
>>certain applications.  This reduces the performance impact of throttling 
>>to non-interactive processes.
>>    
>>
>
>I disagree.  If processors are under an overheat situation, we should
>not consider performance anymore.
>
>  
>
I am in agrement that performance doesn't matter in a CPU thermal 
emergency.  In fact no software throttling would be reliable enough (or 
fast enough) to prevent problems consistently.  I see this governor as a 
preventative measure to reduce day-to-day thermal stress not as an an 
emergency stopgap.  The possible advantages of the governor I see are:

1)  The higher the temperature at which a CPU runs the lower its life.  
A common rule of thumb is that increasing operating temperature by 10C 
cuts CPU life in half.  CPU throttling does not cut in until an 
emergency occurs (which can be often on a laptop).  It would be useful 
to reduce this stress
2)  Quieter operation by reducing the amount of time fans have to run.
3)  Reducing the effect of heat on other components of a system 
(particularly the hard drive in a laptop) which are near the CPU.