Message-ID: <20070429111159.GH23638@1wt.eu>
Date:	Sun, 29 Apr 2007 13:11:59 +0200
From:	Willy Tarreau <w@....eu>
To:	Thomas Gleixner <tglx@...utronix.de>
Cc:	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, Con Kolivas <kernel@...ivas.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 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

-
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