RE: [PATCH] cpufreq_ondemand

[Pallipadi, Venkatesh]

>-----Original Message-----
>From: Con Kolivas [mailto:kernel@xxxxxxxxxxx] 
>Sent: Sunday, October 17, 2004 3:36 PM
>To: Alexander Clouter
>Cc: Pallipadi, Venkatesh; cpufreq@xxxxxxxxxxxxxxxx; 
>linux-kernel@xxxxxxxxxxxxxxx
>Subject: Re: [PATCH] cpufreq_ondemand
>
>Alexander Clouter wrote:
>>> 3. (major) the scaling up and down of the cpufreq is now 
>smoother.  I found 
>> 	it really nasty that if it tripped < 20% idle time that 
>the freq was 
>> 	set to 100%.  This code smoothly increases the cpufreq 
>as well as 
>> 	doing a better job of decreasing it too
>
>I'd much prefer it shot up to 100% or else every time the cpu 
>usage went 
>up there'd be an obvious lag till the machine ran at it's 
>capable speed. 
>  I very much doubt the small amount of time it spent at 100% 
>speed with 
>the default design would decrease the battery life 
>significantly as well.
>

True. The current ondemand behaviour is by design. When CPU 
is at the lowest freq, and there is a sudden surge in load, 
we want it to go to max freq immediately, rather than wait 
for some more polling intervals. If max freq is too high, 
it will naturally lower to some intermediate freq later. 

We can never accurately predict freq for some future load. 
Say a CPU capable of 600, 800, 1000, 1200 and 1400 KHz, is 
running at 600 and we have sudden 100% CPU utilization, then 
we cannot precisely say which should be the next freq. It 
can be any of the higher possible freqs. And we felt performance 
should get a higher priority whenever there is some 
tradeoffs like this.

Thanks,
Venki
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/