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
- References:
- ondemand cpufreq ineffective in 2.6.12 ?
- From: Ken Moffat <[email protected]>
- Re: ondemand cpufreq ineffective in 2.6.12 ?
- From: Con Kolivas <[email protected]>
- Re: ondemand cpufreq ineffective in 2.6.12 ?
- From: Lee Revell <[email protected]>
- ondemand cpufreq ineffective in 2.6.12 ?
- Prev by Date: [PATCH] device-mapper: Fix target suspension oops.
- Next by Date: Re: Merging relayfs?
- Previous by thread: Re: ondemand cpufreq ineffective in 2.6.12 ?
- Next by thread: Re: ondemand cpufreq ineffective in 2.6.12 ?
- Index(es):
