i'm pleased to announce release -v9 of the CFS scheduler patchset. (The
main goal of CFS is to implement "desktop scheduling" with as high
quality as technically possible.)
The CFS patch against v2.6.21.1 (or against v2.6.20.10) can be
downloaded from the usual place:
http://people.redhat.com/mingo/cfs-scheduler/
-v9 is a small fixes-only release:
6 files changed, 34 insertions(+), 29 deletions(-)
it includes small fixlets, the most notable of which is the 64-bit SMP
balancing fix from Balbir Singh. Things are clearly calming down and
there's been no report of interactivity regression against -v8 so far,
which is certainly promising. So please try to break -v9 :-)
Changes since -v8:
- SMP balancing fix for powerpc/64-bit. (Balbir Singh)
- build warning fix and microoptimization: sched_find_first_bit() only
needs to cover 100 priority levels. (Mike Galbraith)
- fix long initial delay in tasks reniced in a positive direction.
(reported by Al Boldi)
- fix missing syscall_table.S entry for sys_sched_yield_to.
(noticed by Vegard Nossum)
- small tweaks to the /proc/sched_debug output
As usual, any sort of feedback, bugreport, fix and suggestion is more
than welcome,
Ingo
Ingo Molnar <mingo <at> elte.hu> writes:
> i'm pleased to announce release -v9 of the CFS scheduler patchset. (The
> main goal of CFS is to implement "desktop scheduling" with as high
> quality as technically possible.)
Now that Andrew decided to kick scheduler patches out of -mm, can we have for-mm
cfs and sd patchsets pretty please?
Regards,
--
Nicolas Mailhot
Hi Ingo,
I just thought I would mention this, because it is certainly on my
mind. I can't help
wondering if other folks are also concerned about this. The thing is,
why don't you
just send your patches to Con who got this whole ball rolling and did a bunch of
great work, proving beyond any reasonable doubt that he is capable of
maintaining
this subsystem, whatever algorithm is finally adopted? Are you worried that Con
might steal your thunder? That somehow the scheduler is yours alone? That you
might be perceived as less of a genius if somebody else gets credit
for their good
work? NIH?
My perception is that you barged in to take over just when Con got things moving
after the scheduler sat and rotted for several years. If that is in
any way accurate,
then shame on you.
Regards,
Daniel
On Mon, 2007-05-07 at 03:02 -0700, Daniel Phillips wrote:
> Hi Ingo,
>
> I just thought I would mention this, because it is certainly on my
> mind. I can't help
> wondering if other folks are also concerned about this. The thing is,
> why don't you
> just send your patches to Con who got this whole ball rolling and did a bunch of
> great work, proving beyond any reasonable doubt that he is capable of
> maintaining
> this subsystem, whatever algorithm is finally adopted? Are you worried that Con
> might steal your thunder? That somehow the scheduler is yours alone? That you
> might be perceived as less of a genius if somebody else gets credit
> for their good
> work? NIH?
>
> My perception is that you barged in to take over just when Con got things moving
> after the scheduler sat and rotted for several years. If that is in
> any way accurate,
> then shame on you.
Nice flame bait. There's a hell of a lot I could say about this, but
I'll just leave it.
-Mike
On 5/7/07, Daniel Phillips <[email protected]> wrote:
> Hi Ingo,
>
> I just thought I would mention this, because it is certainly on my
> mind. I can't help
> wondering if other folks are also concerned about this. The thing is,
> why don't you
> just send your patches to Con who got this whole ball rolling and did a bunch of
> great work, proving beyond any reasonable doubt that he is capable of
> maintaining
> this subsystem, whatever algorithm is finally adopted? Are you worried that Con
> might steal your thunder? That somehow the scheduler is yours alone? That you
> might be perceived as less of a genius if somebody else gets credit
> for their good
> work? NIH?
>
> My perception is that you barged in to take over just when Con got things moving
> after the scheduler sat and rotted for several years. If that is in
> any way accurate,
> then shame on you.
Daniel, I can't hold a candle to your abilities and I respect your
talents and Linux contributions but what are your motives with this
flame?
I think injecting such uninformed/speculative negativity is an awkward
and misplaced distraction. If you look at the archives there was a
flurry of (sometimes heated) discussion between Con and Ingo. They
seemed to bury the hatchet and get back to critical discussion and
analysis of CFS et al.
Maybe I'm naive and/or missing something but Ingo doesn't seem to be
the glory whore type. He clearly has a strong interest in improving
Linux and brings his unique abilities to bear on very complex Linux
subsystems. We should be grateful that he has elected to dedicate so
much time to improving the CPU scheduler. Ingo has injected new
momentum and innovation, yes he leveraged Con's work. But to be
clear: he did so in an open forum and has engaged Con and the rest of
LKML the entire time.
Mike
Daniel Phillips wrote:
> Hi Ingo,
>
> I just thought I would mention this, because it is certainly on my
> mind. I can't help wondering if other folks are also concerned about
> this. The thing is, why don't you just send your patches to Con who
> got this whole ball rolling and did a bunch of great work, proving
> beyond any reasonable doubt that he is capable of maintaining this
> subsystem, whatever algorithm is finally adopted? Are you worried
> that Con might steal your thunder? That somehow the scheduler is
> yours alone? That you might be perceived as less of a genius if
> somebody else gets credit for their good work? NIH?
>
> My perception is that you barged in to take over just when Con got
> things moving after the scheduler sat and rotted for several years.
> If that is in any way accurate, then shame on you.
>
Clearly you have no idea what's going on, or how development is done.
These are mutually exclusive different ideas on what constitutes an
optimal scheduler, and not in any way improvements on the same thing,
but total replacements for the algorithm of the scheduler.
And Ingo has been doing scheduler work for a very long time, while until
recently Con was working on the staircase scheduler as a solution for
desktop use, and it was not (to my taste) a candidate for a general
scheduler until the deadline discussion and some ideas from wli resulted
in improvements resulting in more robust performance under typical
server loads.
You also seem to be unaware of the work done by Nick Piggin in
nicksched. There are a lot of mutually incompatible approaches being
evaluated, and that's good for the future.
--
Bill Davidsen <[email protected]>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
On Mon, May 07, 2007 at 10:03:46AM -0400, Bill Davidsen wrote:
> Clearly you have no idea what's going on, or how development is done.
> These are mutually exclusive different ideas on what constitutes an
> optimal scheduler, and not in any way improvements on the same thing,
> but total replacements for the algorithm of the scheduler.
> And Ingo has been doing scheduler work for a very long time, while until
> recently Con was working on the staircase scheduler as a solution for
> desktop use, and it was not (to my taste) a candidate for a general
> scheduler until the deadline discussion and some ideas from wli resulted
> in improvements resulting in more robust performance under typical
> server loads.
> You also seem to be unaware of the work done by Nick Piggin in
> nicksched. There are a lot of mutually incompatible approaches being
> evaluated, and that's good for the future.
I'd like to add in Mike Kravetz, Hubertus Franke, and Peter Williams
for mention here. There are doubtlesss many others also deserving some
recognition for significant past work.
-- wli
* William Lee Irwin III <[email protected]> wrote:
> > You also seem to be unaware of the work done by Nick Piggin in
> > nicksched. There are a lot of mutually incompatible approaches being
> > evaluated, and that's good for the future.
>
> I'd like to add in Mike Kravetz, Hubertus Franke, and Peter Williams
> for mention here. There are doubtlesss many others also deserving some
> recognition for significant past work.
Peter is certainly one of the most active current contributors to the
scheduler! And the list goes on: here is the list of the 71 people who
contributed to the scheduler recently (based on the git log which covers
the past 2 years):
Nick Piggin, Con Kolivas, Suresh B Siddha, Christoph Lameter,
Oleg Nesterov, Linus Torvalds, Peter Williams, Kenneth W Chen,
Steven Rostedt, Srivatsa Vaddagiri, Mike Galbraith, Chandra Seetharaman,
Thomas Gleixner, Heiko Carstens, Robert P. J. Day, Paul Jackson,
Matt Mackall, Kirill Korotaev, John Hawkes, Jack Steiner, Andrew Morton,
Andreas Mohr, Andi Kleen, Al Viro, Zachary Amsden, Tim Chen, Shailabh Nagar,
Satoru Takeuchi, Renaud Lienhart, Randy Dunlap, Peter Zijlstra,
Paul Mackerras, Olivier Croquette, Nigel Cunningham, Nathan Lynch,
Miguel Ojeda Sandonis, M.Baris Demiray, Martin Waitz, Martin Andersson,
Mark Fasheh, Keith Owens, Kamezawa Hiroyuki, Jim Houston, Jesper Juhl,
Jens Axboe, Jeff Garzik, Jay Lan, Jason Baron, Jan Kara, Hugh Dickins,
Helge Deller, Greg Banks, Eric Dumazet, Dinakar Guniguntala, David Quigley,
Dave Jones, Chuck Ebbert, Christoph Hellwig, Chris Caputo, Chen Shang,
Borislav Petkov, Bibo Mao, Benjamin LaHaise, Arjan van de Ven,
Anton Blanchard, Andreas Steinmetz, Alexey Dobriyan, Akinobu Mita,
Adrian Bunk.
and there are countless others from the 10 years not covered by the git
log, so the list is far from complete.
Furthermore, here's the 'toplist' of number-of-authors-per-source-file
list of linux/*/*.c files (which covers most of the core kernel source
files, based on 2 years of git metadata):
kernel/sched.c: 72
mm/page_alloc.c: 60
mm/slab.c: 55
kernel/fork.c: 54
kernel/sysctl.c: 47
mm/filemap.c: 42
kernel/timer.c: 42
kernel/sys.c: 41
mm/memory.c: 40
fs/buffer.c: 39
kernel/module.c: 38
kernel/exit.c: 38
fs/exec.c: 38
net/socket.c: 36
kernel/signal.c: 36
init/main.c: 36
block/ll_rw_blk.c: 35
fs/binfmt_elf.c: 34
mm/shmem.c: 33
fs/namei.c: 33
[...]
the scheduler is one of the most diversely and most actively hacked
subsystems in the kernel.
Ingo