Re: ondemand cpufreq ineffective in 2.6.12 ?

[Con Kolivas <kernel@kolivas.org>]

On Wed, 13 Jul 2005 00:57, Lee Revell wrote:
> On Tue, 2005-07-12 at 21:52 +1000, Con Kolivas wrote:
> > > Well, it's just the default settings of the kernel which has changed.
> > > If you want the old behaviour, you can use (with your admin hat): echo
> > > 1 > /sys/devices/system/cpu/cpu0/cpufreq/ondemand/ignore_nice IMHO it
> > > seems quite fair, if you have a process nice'd to 10 it probably means
> > > you are not in a hurry.
> >
> > That's not necessarily true. Most people use 'nice' to have the cpu bound
> > task not affect their foreground applications, _not_ because they don't
> > care how long they take.
>
> But the scheduler should do this on its own!

That is a most unusual thing to tell the person who tuned the crap out of the 
2.6 scheduler so that it would do this.

> If people are having to 
> renice kernel compiles to maintain decent interactive performance (and
> yes, I have to do the same thing sometimes) the scheduler is BROKEN,
> period.

Two tasks being the same nice level still implies they should receive the same 
proportion of cpu. Anything else breaks the implied fairness of nice levels. 
Whether you agree with this approach or not, it is expected. No, cpu 
distribution is never _perfectly_ split 50/50 when nice levels are the same 
but we try our best to do so while maintaining interactivity. 

A more useful argument would be that you'd like to have two sets of nice 
levels - one perhaps called latnice implying which tasks you want latency 
critical but still want to have the same cpu and one called cpunice which 
affects the amount of cpu but not the latency. Some would like complete 
control over both nices while others want the scheduler to do everything for 
them. Either way, you want a compile to be both latnice and cpunice. Our 
current nice is both latnice and cpunice, and if nice levels are equal the 
scheduler does a heck of a lot of its own latnice based on behaviour. It's 
not perfect and nothing ever is. 

Cheers,
Con

Attachment: pgpvAIpNTqm4h.pgp
Description: PGP signature