[lkml]   [1999]   [Jul]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 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: |
| Linux Memory Management site: |
| Nederlandse Linux documentatie: |

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:53    [W:0.086 / U:0.168 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site