Date:	Sun, 29 Apr 2007 21:46:15 +1000
From:	Con Kolivas <kernel@...ivas.org>
To:	Willy Tarreau <w@....eu>
Cc:	Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...e.hu>,
	Kasper Sandberg <lkml@...anurb.dk>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Gene Heskett <gene.heskett@...il.com>,
	linux-kernel@...r.kernel.org, Nick Piggin <npiggin@...e.de>,
	Mike Galbraith <efault@....de>,
	Arjan van de Ven <arjan@...radead.org>,
	Peter Williams <pwil3058@...pond.net.au>, caglar@...dus.org.tr,
	Mark Lord <lkml@....ca>, Zach Carter <linux@...hcarter.com>,
	buddabrod <buddabrod@...il.com>
Subject: Re: [patch] CFS scheduler, -v6

On Sunday 29 April 2007 21:11, Willy Tarreau wrote:
> On Sun, Apr 29, 2007 at 12:30:54PM +0200, Thomas Gleixner wrote:
> > Willy,
> >
> > On Sun, 2007-04-29 at 09:16 +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.
> >
> > Oh no, we really do _NOT_ want to throw SD or anything else at mainline
> > in a hurry just for not wasting time on comparing to the current
> > scheduler.
>
> It is not about doing it in a hurry. I see SD as a small yet efficient
> update to current scheduler. It's not perfect, probably not much extensible
> but the risks of breaking anything are small given the fact that it does
> not change much of the code or behaviour.
>
> IMHO, it is something which can provide users with a useful update while
> leaving us with some more time to carefully implement the features of CFS
> one at a time, and if it requires 5 versions, it's not a problem.
>
> > I agree that CFS is the more interesting target and I prefer to push the
> > more interesting one even if it takes a release cycle longer. The main
> > reason for me is the design of CFS. Even if it is not really modular
> > right now, it is not rocket science to make it fully modular.
> >
> > Looking at the areas where people work on, e.g. containers, resource
> > management, cpu isolation, fully tickless systems ...., we really need
> > to go into that direction, when we want to avoid permanent tinkering in
> > the core scheduler code for the next five years.
> >
> > As a sidenote: I really wonder if anybody noticed yet, that the whole
> > CFS / SD comparison is so ridiculous, that it is not even funny anymore.
>
> Contrarily to most people, I don't see them as competitors. I see SD as
> a first step with a low risk of regression, and CFS as an ultimate
> solution relying on a more solid framework.
>
> > CFS modifies the scheduler and nothing else, SD fiddles all over the
> > kernel in interesting ways.
>
> Hmmm I guess you confused both of them this time. CFS touches many places,
> which is why I think the testing coverage is still very low. SD can be
> tested faster. My real concern is : are there still people observing
> regressions with it ? If yes, they should be fixed before even being
> merged. If no, why not merge it as a fix for the many known corner cases
> of current scheduler ? After all, it's already in -mm.
>
> Willy

Willy, you're making far too much sense. Are you replying to the correct 
mailing list?

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

Powered by blists - more mailing lists