Re: [PATCH][2.5.32] CPU frequency and voltage scaling (0/4)

[Padraig Brady <padraig.brady@corvil.com>]

Linus Torvalds wrote:
> On 28 Aug 2002, Alan Cox wrote:
> 
>>Systems designers are designing on the basis of thermal slowdowns being
>>the optimal way to build some systems. Its actually quite reasonable for
>>many workloads.
> 
> Absolutely. Thermal policy is often an overriding thing, where even 
> non-transmeta CPU's will simply do the decision "on their own", without 
> input from the OS. That's simply because some designs will literally not 
> work above certain temperatures and do not have the heat sink capacity to 
> get out of a tight spot by purely external cooling. 
> 
> But that's just one part of it. Even aside from thermal concerns, you want 
> to drop frequency aggressively when the machine is idle, because dropping 
> the frequency allows you to drop the voltage and effetively gets you a 
> cubed power reduction (which not only saves your battery, but also cools 
> the chip down so that when you _do_ start going full speed again you have 
> more thermal headroom).
> 
> So in order to avoid the thermal shutdown, you need to be proactive about 
> the frequency. Which again means that a user-level "once a second" or 
> "once in a blue moon" approach is fundamentally flawed.

Just a data point from my application. First of all with VIA CPUs
there is a 1ms delay per change when it resyncs things, so it's
not practical to do it very often or for realtime apps etc.
My application was purely a heat reduction exercise where the
timescale from 0°C to 70°C was around 10 minutes at max voltage/frequency,
so it could easily be controlled by a userspace application.
In fact I didn't control it manually and only set the frequency
(for which the appropriate voltage was chosen by the cpufreq code)
at system startup.

> I don't disagree with _also_ being able to set the frequency statically. 
> However, I do disagree with an interface that seems to be _purely_ 
> designed for this, and nothing else. 
> 
> 		Linus

Pádraig.