Re: new scheduler

[Dominik Kubla <dominik.kubla@uni-mainz.de>]

On Tue, Mar 16, 1999 at 01:46:30AM +0100, Rik van Riel wrote:
> 
> - better realtime scheduling
> - better throughput (on SMP systems) by less memory contention
>   and less unneeded context switches
> - better interactive response under load
> - load-isolation between users (if user A and B run
>   processes and A has 10 and B only 1, it would be
>   fairer if both users each got 50% of the CPU)

Wouldn't it  be better  to make the  max. number of  used CPU's  a resource
limit?  That would  tie in  nicely with  the notion  of scheduling  classes
mentioned below.

> - simplicity, less overhead
> - larger difference between niced and non-niced CPU
>   usage

You might want to add the following:

- Definition of CPU subcomplexes on MPP systems. (a la HP/Convex)

- Process  migration  from  node to  node  (a la  VMS,  useful for  Beowulf
  clusters)

- Definition of  more scheduler  classes ("interactive",  "batch", "system"
  and  "real-time"   seem  to  be   a  sensible  definition  for   most  RL
  applications)

- Locking of processes on CPU's (If you ever watched how DEC Unix is moving
  processes around on an idle machine, you know why this is good!)

Of course there is always the  question of complexity versus gain, but IMHO
we should  at least discuss  it. Maybe these  things can be  made optional?
Meaning we  have a default  scheduler, which is  a reworked version  of the
current one, and one or more  optional, more specialized types, eg for MPP,
embedded and/or real-time applications.

Yours,
  Dominik Kubla
-
Linux-future: thinking about the future of the Linux kernel
Archive:      http://humbolt.nl.linux.org/lists/
Wish list:    http://users.ox.ac.uk/~mert0236/linux-future.html