lkml.org 
[lkml]   [2006]   [Apr]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [patch][rfc] quell interactive feeding frenzy
    From
    Date
    On Fri, 2006-04-07 at 23:56 +1000, Con Kolivas wrote:
    > On Friday 07 April 2006 23:37, Mike Galbraith wrote:
    > > On Fri, 2006-04-07 at 22:56 +1000, Con Kolivas wrote:
    > > > This mechanism is designed to convert on-runqueue waiting time into
    > > > sleep. The basic reason is that when the system is loaded, every task is
    > > > fighting for cpu even if they only want say 1% cpu which means they never
    > > > sleep and are waiting on a runqueue instead of sleeping 99% of the time.
    > > > What you're doing is exactly biasing against what this mechanism is in
    > > > place for. You'll get the same effect by bypassing or removing it
    > > > entirely. Should we do that instead?
    > >
    > > Heck no. That mechanism is just as much about fairness as it is about
    > > intertactivity, and as such is just fine and dandy in my book... once
    > > it's toned down a bit^H^H^Htruckload. What I'm doing isn't biasing
    > > against the intent, I'm merely straightening the huge bend in favor of
    > > interactive tasks who get this added boost over and over again, and
    > > restricting the general effect to something practical.
    >
    > Have you actually tried without that mechanism?

    Yes. We're better off with it than without.

    > > Just look at what that mechanism does now with a 10 deep queue. Every
    > > dinky sleep can have an absolutely huge gob added to it, the exact worst
    > > case number depends on how many cpus you have and whatnot. Start a slew
    > > of tasks, and you are doomed to have every task that sleeps for the
    > > tiniest bit pegged at max interactive.
    >
    > I'm quite aware of the effect it has :)

    Ok. Do we then agree that it makes 2.6 unusable for small servers, and
    that this constitutes a serious problem? :)

    > > Maybe what I did isn't the best that can be done, but something has to
    > > be done about that. It is very b0rken under heavy load.
    >
    > Your compromise is as good as any.

    Ok.

    -Mike

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2006-04-07 16:16    [W:0.023 / U:1.204 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site