Re: [patch] CFS scheduler, -v6
From: Thomas Gleixner
Date: Sun Apr 29 2007 - 06:29:24 EST
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
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.
CFS modifies the scheduler and nothing else, SD fiddles all over the
kernel in interesting ways.
This is worse than apples and oranges, it's more like apples and
Can we please stop this useless pissing contest and sit down and get a
modular design into mainline, which allows folks to work and integrate
their "workload X perfect scheduler" and gives us the flexibility to
adjust to the needs of upcoming functionality.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/