Re: [patch] CFS scheduler, -v6

[Willy Tarreau <w@1wt.eu>]

On Sun, Apr 29, 2007 at 12:54:36AM -0700, William Lee Irwin III wrote:
> On Sun, Apr 29, 2007 at 09:16:27AM +0200, Willy Tarreau wrote:
> > In fact, what I'd like to see in 2.6.22 is something better for everybody
> > and with *no* regression, even if it's not perfect. I had the feeling
> > that SD matched that goal right now, except for Mike who has not tested
> > recent versions. Don't get me wrong, I still think that CFS is a more
> > interesting long-term target. But it may require more time to satisfy
> > everyone. At least with one of them in 2.6.22, we won't waste time
> > comparing to current mainline.
> 
> I think it'd be a good idea to merge scheduler classes before changing
> over the policy so future changes to policy have smaller code impact.
> Basically, get scheduler classes going with the mainline scheduler.
> 
> There are other pieces that can be merged earlier, too, for instance,
> the correction to the comment in init/main.c. Directed yields can
> probably also go in as nops or -ENOSYS returns if not fully implemented,
> though I suspect there shouldn't be much in the way of implementing them.
> p->array vs. p->on_rq can be merged early too.

I agree that merging some framework is a good way to proceed.

> Common code for rbtree-based priority queues can be factored out of
> cfq, cfs, and hrtimers.

In my experience, rbtrees are painfully slow. Yesterday, I spent the
day replacing them in haproxy with other trees I developped a few
years ago, which look like radix trees. They are about 2-3 times as
fast to insert 64-bit data, and you walk through them in O(1). I have
many changes to apply to them before they could be used in kernel, but
at least I think we already have code available for other types of trees.

> There are extensive /proc/ reporting changes, large chunks of which
> could go in before the policy as well.
> 
> I'm camping in this weekend, so I'll see what I can eke out.

good luck !

Willy