lkml.org 
[lkml]   [1998]   [Nov]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:45    [from the cache]
©2003-2011 Jasper Spaans