Re: ondemand cpufreq ineffective in 2.6.12 ?

Con Kolivas
2005-07-12T21:29:01Z

[-- Attachment #1: Type: text/plain, Size: 2033 bytes --]

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 #2: Type: application/pgp-signature, Size: 189 bytes --]