Messages in this thread | | | Date | Wed, 28 Jul 1999 20:59:09 +0200 (CEST) | From | Rik van Riel <> | Subject | Re: low priority soft RT? |
| |
On Tue, 27 Jul 1999, Mitchell Blank Jr wrote: > Stephen C. Tweedie wrote: > > There's a much, much easier way --- just revoke the SCHED_IDLE > > scheduling class when a process explicitly calls schedule(). That > > automatically takes care of every single case where a process gives up > > the CPU from inside the kernel. The only special case then becomes the > > schedule inside return_to_user, where we want to keep SCHED_IDLE > > intact. > > > > However, that adds code to two of the hottest paths in the whole > > kernel. Not nice. > > Then perhaps the best compromise is to make SCHED_IDLE a compile > time option. If you want to support "true" SCHED_IDLE you must > take the performance hit in schedule() to be safe from lock > starvation. If you don't compile "true" SCHED_IDLE into the kernel > it would just get mapped to be the same as 'nice 19' or whatever.
Unfortunately, that won't really do. We can, of course, just increase the range of nice levels, but all that does is increase the current "maximum deadlock time".
It's all a question of compromise. We have to choose and my patch gives (through sysctl) root the choice whether to enable SCHED_IDLE or not.
I know there are quite a lot of people willing to put rc5des and other distributed computing apps on large Beowulf clusters if we have SCHED_IDLE. It's also useful for compressing MP3s, etc... It's turned off by default and people have to enable it by hand if they feel they need it.
I really don't see why we should keep root from shooting himself in the foot -- IIRC that's been Unix tradition :)
Rik -- Open Source: you deserve to be in control of your data. +-------------------------------------------------------------------+ | Le Reseau netwerksystemen BV: http://www.reseau.nl/ | | Linux Memory Management site: http://www.linux.eu.org/Linux-MM/ | | Nederlandse Linux documentatie: http://www.nl.linux.org/ | +-------------------------------------------------------------------+
- 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/
| |