[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070415195748.GA16004@elte.hu>
Date: Sun, 15 Apr 2007 21:57:48 +0200
From: Ingo Molnar <mingo@...e.hu>
To: William Lee Irwin III <wli@...omorphy.com>
Cc: Willy Tarreau <w@....eu>,
"Eric W. Biederman" <ebiederm@...ssion.com>,
Nick Piggin <npiggin@...e.de>, linux-kernel@...r.kernel.org,
Linus Torvalds <torvalds@...ux-foundation.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Con Kolivas <kernel@...ivas.org>,
Mike Galbraith <efault@....de>,
Arjan van de Ven <arjan@...radead.org>,
Thomas Gleixner <tglx@...utronix.de>,
Jiri Slaby <jirislaby@...il.com>,
Alan Cox <alan@...rguk.ukuu.org.uk>
Subject: Re: [Announce] [patch] Modular Scheduler Core and Completely Fair Scheduler [CFS]
* William Lee Irwin III <wli@...omorphy.com> wrote:
> On Sun, Apr 15, 2007 at 09:20:46PM +0200, Ingo Molnar wrote:
> > so Linus was right: this was caused by scheduler starvation. I can
> > see one immediate problem already: the 'nice offset' is not divided
> > by nr_running as it should. The patch below should fix this but i
> > have yet to test it accurately, this change might as well render
> > nice levels unacceptably ineffective under high loads.
>
> I've been suggesting testing CPU bandwidth allocation as influenced by
> nice numbers for a while now for a reason.
Oh I was very much testing "CPU bandwidth allocation as influenced by
nice numbers" - it's one of the basic things i do when modifying the
scheduler. An automated tool, while nice (all automation is nice)
wouldnt necessarily show such bugs though, because here too it needed
thousands of running tasks to trigger in practice. Any volunteers? ;)
Ingo
-
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