[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070418003649.GA7293@gnuppy.monkey.org>
Date: Tue, 17 Apr 2007 17:36:49 -0700
From: Bill Huey (hui) <billh@...ppy.monkey.org>
To: "Michael K. Edwards" <medwards.linux@...il.com>
Cc: William Lee Irwin III <wli@...omorphy.com>,
Peter Williams <pwil3058@...pond.net.au>,
Ingo Molnar <mingo@...e.hu>, Nick Piggin <npiggin@...e.de>,
Mike Galbraith <efault@....de>,
Con Kolivas <kernel@...ivas.org>, ck list <ck@....kolivas.org>,
linux-kernel@...r.kernel.org,
Linus Torvalds <torvalds@...ux-foundation.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Arjan van de Ven <arjan@...radead.org>,
Thomas Gleixner <tglx@...utronix.de>,
"Bill Huey (hui)" <billh@...ppy.monkey.org>
Subject: Re: [Announce] [patch] Modular Scheduler Core and Completely Fair Scheduler [CFS]
On Tue, Apr 17, 2007 at 04:52:08PM -0700, Michael K. Edwards wrote:
> On 4/17/07, William Lee Irwin III <wli@...omorphy.com> wrote:
> >The ongoing scheduler work is on a much more basic level than these
> >affairs I'm guessing you googled. When the basics work as intended it
> >will be possible to move on to more advanced issues.
...
Will probably shouldn't have dismissed your points but he probably means
that can't even get at this stuff until fundamental are in place.
> Clock scaling schemes that aren't integral to the scheduler design
> make a bad situation (scheduling embedded loads with shotgun
> heuristics tuned for desktop CPUs) worse, because the opaque
> heuristics are now being applied to distorted data. Add a "smoothing"
> scheme for the distorted data, and you may find that you have
> introduced an actual control-path instability. A small fluctuation in
> the data (say, two bursts of interrupt traffic at just the right
> interval) can result in a long-lasting oscillation in some task's
> "dynamic priority" -- and, on a fully loaded CPU, in the time that
> task actually gets. If anything else depends on how much work this
> task gets done each time around, the oscillation can easily propagate
> throughout the system. Thrash city.
Hyperthreading issues are quite similar that clock scaling issues.
Con's infrastructures changes to move things in that direction were
rejected, as well as other infrastructure changes, further infuritating
Con to drop development on RSDL and derivatives.
bill
-
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