>
> >From: Nathan Hand <nathanh@chirp.com.au>
>
> >However I don't think modularised schedulers are nearly as trivial
> >as you and the poster before you are suggesting.
>
> You probably haven't heard of Vassal. I hadn't until yesterday. See
>
> http://research.microsoft.com/~mbj/papers/UsenixNT98/vassal.html
>
> This added, and I quote:
>
> The Vassal changes made to the Windows NT kernel to support
> multi-policy scheduling added 188 lines of C code, added 61 assembly
> instructions, and replaced 6 assembly instructions.
>
> The proof-of-concept external scheduler described earlier required
> only 116 lines of C code and no assembly language. We believe these
> are extremely low code size numbers for the increased functionality
> that we achieved.
>
> I don't believe that modular schedulers are trivial to add, but they
> certainly don't have to involve a lot of code. Also, having screwed
> around with the Mach scheduler to make it do something utterly
> different than was intended originally, I don't think of problems like
> this as too hard. This is perhaps impetuous. Also, Mach tended toward
> the design-heavy end of the OS spectrum. Linux is extremely clean, but
> not always design-clean. Linus is a good decision maker on the
> elegance-versus-performance tradeoff, and the Linux scheduling code is
> not quite as packaged as the stuff in Mach or NT. This is a good thing
> for almost every reason, except when you want to do something very new.
>
> >From: Richard Gooch <rgooch@atnf.csiro.au>
>
> >Agreed. The proposal I saw looks really fancy and powerful, but I
> >suspect it's awfully bloated. Just to have the basic framework in
> >place would probably make the core scheduler 10 times slower than a
> >simple scheduler (like Linux).
>
> Well, in the Vassal case, having the hooks in the scheduler had
> essentially *NO* effect (lost in the statistical noise).
>
> With an external scheduler loaded, it slowed the scheduler down by
> about 8%. The NT scheduler isn't very zippy compared to the Linux one
> anyway, so its hard to predict which way this figure would go. Also,
> the Vassal implementation was just a prototype, so it could get
> better, or it could (unlikely) get worse.
>
> --p
>
> -
> 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/
>
-
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/