Re: Comments on the KSE option

> The aim of the fair scheduling code is to ensure that if you, as a user, 
> make a process that starts 1000 threads, and I as a user, make an 
> unthreaded process, then I can still get to the CPU at somewhat similar
> rates to you.  A naive scheduler would give you 1000 cpu slots and me 1.

The default may be to give each process the same share but
in general one would want even more control over scheduling.
For instance I may want one group of processes to get 10%
share (it may be encoding/serving a video stream in real
time) and the remaining shared by everyone else.  You need
waited fair queuing or some such.  This can allow one to
structure an application in a natural way without having to
worry about how scheduling will be impacted by a choice of
threads vs processes.

Have you guys looked at any networking related papers on
scheduling?  I see a lot of similarities in the goals and
some algorithms may be useful.  One can think of a tcp stream
or traffic between two endpoints as equivalent of a thread.

May be by throwing out all of KSE and simplifying the
scheduler you/we have an opportunity to apply the lessons
learned and come up with a leaner, more efficient and
flexible design.  The default scheduler can be dirt simple
but easy to replace or enhance, may be with a loadble module,
so that one can experiment with different algorithms without
having to take the system down as well as punt to a user
process for more complex decisions.  This is assuming a very
simple plugin API is possible (definitely not a given).

FWIW.

-- bakul