Messages in this thread | | | Date | Wed, 11 Nov 1998 14:17:44 +0100 (CET) | From | Rik van Riel <> | Subject | Re: Schedule idle |
| |
On Wed, 11 Nov 1998, Richard Gooch wrote:
[SNIP]
> even if we rip out the RT scheduling classes and > not include SCHED_IDLE, the sleep-with-lock bug still presents a > problem. A heavily niced process (nice 19) which messes with the FS > can significantly degrade the performance of the FS for other > processes. Imagine the following scenario: > > - nice 19 process bangs on FS > - nice 4 process eats CPU > - normal users try to use FS. > > Here we don't get deadlock, but we do get lockouts while the nice 19 > process goes to sleep holding a resource lock. Eventually the user > processes will get access to the FS again, but only after a long wait.
Andrea, Victor, what should we do about this, instead of ridiculing things like SCHED_{FIFO,RR,IDLE} in the normal kernel?
Maybe something like a flag (p->locks_held) which is upped on every lock acquired and lowered on each lock unlocked? Then we can give a certain scheduling preference to a process holding a lock so that the lock will be freed with huge certainty when (the process with the lock != last). That way deadlocks will be no longer than the time between two or three schedules.
This could mean abandoning the low-latency multiple runqueue idea by Richard though, unless we make for an even more complex scheme. This is a shame, Richard's scheme really was an advantage for low-overhead switching.
Btw, I've just come up with a new scheduling class (not in code, consider yourself happy) especially for multimedia apps. The idea is to give them a large bonus in goodness() but to charge them double on CPU used. This way those apps get better response time than normal apps but only half the CPU (when having to compete full-time). We could make that class available to normal users because the app only gains in responsiveness when it uses less CPU than half it's fair share. If it uses more it will have worse performance.
cheers,
Rik -- slowly getting used to dvorak kbd layout... +-------------------------------------------------------------------+ | Linux memory management tour guide. H.H.vanRiel@phys.uu.nl | | Scouting Vries cubscout leader. http://www.phys.uu.nl/~riel/ | +-------------------------------------------------------------------+
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |