On Sun, Apr 29, 2007 at 02:13:30PM +0200, Thomas Gleixner wrote: > SD is a one to one replacement of the existing scheduler guts - with a > different behaviour. > CFS is a huge step into a modular and hierarchical scheduler design, > which allows more than just implementing a clever scheduler for a single > purpose. In a hierarchical scheduler you can implement resource > management and other fancy things, in the monolitic design of the > current scheduler (and it's proposed replacement SD) you can't. But SD > can be made one of the modular variants.
The modularity provided is not enough to allow an implementation of mainline, SD, or nicksched without significant core scheduler impact. CFS doesn't have all that much to do with scheduler classes. A weak form of them was done in tandem with the scheduler itself. The modularity provided is sufficiently weak the advantage is largely prettiness of the code. So essentially CFS is every bit as monolithic as mainline, SD, et al, with some dressing that suggests modularity without actually making any accommodations for alternative policies (e.g. reverting to mainline). You'll hit the holes in the driver API quite quickly should you attempt to port mainline to it. You'll hit several missing driver operations right in schedule(), for starters. At some point you may also notice that simple enqueue operations are not all that's there. Representing enqueueing to active vs. expired and head vs. tail are needed for current mainline to be representible by a set of driver operations. It's also a bit silly to remove and re-insert a queue element for cfs (or anything else using a tree-structured heap, which yes, a search tree is, even if a slow one), which could use a reprioritization driver operation, but I suppose it won't oops. You'll also hit the same holes should you attempt to write such a modularity patch for mainline as opposed to porting current mainline to the driver API as-given. It takes a bit more work to get something that actually works for all this, and it borders on disingenuity to suggest that the scheduler class/driver API as it now stands is capable of any such thing as porting current mainline, nicksched, or SD to it without significant code impact to the core scheduler code. So on both these points, I don't see cfs as being adequate as it now stands for a modular, hierarchical scheduler design. If we want a truly modular and hierarchical scheduler design, I'd suggest pursuing it directly and independently of policy, and furthermore considering the representability of various policies in the scheduling class/driver API as a test of its adequacy. -- wli - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
