Re: interactive task starvation

From: Mike Galbraith
Date: Tue Mar 21 2006 - 08:09:44 EST


On Tue, 2006-03-21 at 22:53 +1100, Con Kolivas wrote:
> On Tuesday 21 March 2006 22:18, Ingo Molnar wrote:
> > great work by Mike! One detail: i'd like there to be just one default
> > throttling value, i.e. no grace_g tunables [so that we have just one
> > default scheduler behavior]. Is the default grace_g[12] setting good
> > enough for your workload?
>
> I agree. If anything is required, a simple on/off tunable makes much more
> sense. Much like I suggested ages ago with an "interactive" switch which was
> rather unpopular when I first suggested it.

Let me try to explain why on/off is not sufficient.

You notice how Willy said that his notebook is more responsive with
tunables set to 0,0? That's important, because it's absolutely true...
depending what you're doing. Setting tunables to 0,0 cuts off the idle
sleep logic, and the sleep_avg divisor - both of which were put there
specifically for interactivity - and returns the scheduler to more or
less original O(1) scheduler. You and I both know that these are most
definitely needed in a Desktop environment. For instance, if Willy
starts editing code in X, and scrolls while something is running in the
background, he'll suddenly say hey, maybe this _ain't_ more responsive,
because all of a sudden the starvation added with the interactivity
logic will be sorely missed as my throttle wrings X's neck.

How long should Willy be able to scroll without feeling the background,
and how long should Apache be able to starve his shell. They are one
and the same, and I can't say, because I'm not Willy. I don't know how
to get there from here without tunables. Picking defaults is one thing,
but I don't know how to make it one-size-fits-all. For the general
case, the values delivered will work fine. For the apache case, they
absolutely 100% guaranteed will not.

-Mike

-
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/