lkml.org 
[lkml]   [2007]   [Apr]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [patch] CFS scheduler, -v6
    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

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2007-04-29 10:19    [W:4.154 / U:0.092 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site