Re: [ANNOUNCE][RFC] plugsched-2.0 patches ...

[Peter Williams <pwil3058@bigpond.net.au>]

Marc E. Fiuczynski wrote:
> Peter, thank you for maintaining Con's plugsched code in light of Linus' and
> Ingo's prior objections to this idea.  On the one hand, I partially agree
> with Linus&Ingo's prior views that when there is only one scheduler that the
> rest of the world + dog will focus on making it better. On the other hand,
> having a clean framework that lets developers in a clean way plug in new
> schedulers is quite useful.
> 
> Linus & Ingo, it would be good to have an indepth discussion on this topic.
> I'd argue that the Linux kernel NEEDS a clean pluggable scheduling
> framework.
> 
> Let me make a case for this NEED by example.  Ingo's scheduler belongs to
> the egalitarian regime of schedulers that do a poor job of isolating
> workloads from each other in multiprogrammed environments such as those
> found on Enterprise servers and in my case on PlanetLab (www.planet-lab.org)
> nodes.  This has been rectified by HP-UX, Solaris, and AIX through the use
> of fair share schedulers that use O(1) schedulers within a share.  Currently
> PlanetLab uses a CKRM modified version of Ingo's scheduler.

I'm hoping that the CKRM folks will send me a patch to add their 
scheduler to plugsched :-)

>  Similarly, the
> linux-vserver project also modifies Ingo's scheduler to construct an
> entitlement based scheduling regime. These are not just variants of O(1)
> schedulers in the sense of Con's staircase O(1). Nor is it clear what the
> best type of scheduler is for these environments (i.e., HP-UX, Solaris and
> AIX don't have it fully solved yet either). The ability to dynamically swap
> out schedulers on a production system like PlanetLab would help in
> determining what type of scheduler is the most appropriate.  This is because
> it is non-trivial, if not impossible, to recreate the multiprogrammed
> workloads that we see in a lab.
> 
> For these reasons, it would be useful for plugsched (or something like it)
> to make its way into the mainline kernel as a framework to plug in different
> schedulers.  Alternatively, it would be useful to consider in what way
> Ingo's scheduler needs to support plugins such as the CKRM and Vserver types
> of changes.
> 
> Best regards,
> Marc


-- 
Peter Williams                                   pwil3058@bigpond.net.au

"Learning, n. The kind of ignorance distinguishing the studious."
  -- Ambrose Bierce