On Sun, 2007-04-29 at 05:55 -0700, William Lee Irwin III wrote:
> 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.
I never said, that the current implementation of CFS fits the criteria
of modularity, but it is a step in that direction. I'm well aware that
there is a bunch of things missing and it has hard coded leftovers,
which are related to the current two hard coded policy classes.
> 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.
Ack. I don't worry much whether the CFS policy is better than the SD
one. I'm all for a truly modular design. SD and SCHED_FAIR are good
proofs for it.
tglx
-
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/
