Peter, thank you for maintaining Con's plugsched code in light of Linus' andIngo's prior objections to this idea. On the one hand, I partially agreewith Linus&Ingo's prior views that when there is only one scheduler that therest 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 newschedulers 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 schedulingframework.

Let me make a case for this NEED by example. Ingo's scheduler belongs tothe egalitarian regime of schedulers that do a poor job of isolatingworkloads from each other in multiprogrammed environments such as thosefound 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 useof fair share schedulers that use O(1) schedulers within a share. CurrentlyPlanetLab uses a CKRM modified version of Ingo's scheduler. Similarly, thelinux-vserver project also modifies Ingo's scheduler to construct anentitlement 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 thebest type of scheduler is for these environments (i.e., HP-UX, Solaris andAIX don't have it fully solved yet either). The ability to dynamically swapout schedulers on a production system like PlanetLab would help indetermining what type of scheduler is the most appropriate. This is becauseit is non-trivial, if not impossible, to recreate the multiprogrammedworkloads 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 differentschedulers. Alternatively, it would be useful to consider in what wayIngo's scheduler needs to support plugins such as the CKRM and Vserver typesof changes.