Scheduler-thoughts for v2.5.x

[David Weinehall]

On Mon, 24 Jan 2000, Borislav Deianov wrote:

> 
> In article <Pine.A41.4.21.0001221342300.20830-100000 en yen.acc.umu.se> you wrote:
> > Would it be viable to introduce several different schedulers to chose from
> > in the v2.5 development-tree, as a compile-time option. This way we would
> > solve most of the considerations of workstation vs webserver vs
> > database-server vs ftpserver etc.
> >
> > I haven't got a clue if this is technically possible (well, it IS
> > possible, but the question is whether it's reasonable, or if it would
> > involve rewriting half the kernel to introduce such a change...), and if
> > it is anything that would be interesting.
> 
> My fair scheduler (http://people.cornell.edu/pages/bdd2/fairsched) is
> a compile-time option and is fairly non-intrusive (a bunch of
> one-liners in kernel/sched.c). So I think this is feasable, if you can
> convince people that different schedulers are actually needed.

My idea was that every scheduler would have a file of its own; something
like linux/kernel/sched/blaha1.c blaha2.c etc. Even if its just a few
one-liners in kernel/sched.c, a choice of several schedulers would mean
a LOT of one-liners in sched.c, thus very incomprehensible code.
 
> > Of course, a modular, hot-swappable scheduler would be best, but I figure
> > that'd be pretty awkward to program. Or?
> 
> I know of an alternative scheduler that works as a module for current
> 2.2 (no patches needed). It's binary only but my guess is you don't
> want to look at that code anyway ;)

Doesn't sound like too much fun, no...

/David
  _                                                                 _ 
 // David Weinehall <tao en acc.umu.se> /> Northern lights wander      \\
//  Project MCA Linux hacker        //  Dance across the winter sky // 
\>  http://www.acc.umu.se/~tao/    </   Full colour fire           </ 


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo en vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/