On Thu, 21 Aug 2003 17:53, Mike Galbraith wrote:
> At 03:26 PM 8/21/2003 +1000, Con Kolivas wrote:
> >Unhappy with this latest O16.3-O17int patch I'm withdrawing it, and
> >recommending nothing on top of O16.3 yet.
> >More and more it just seems to be a bandaid to the priority inverting spin
> > on waiters, and it does seem to be of detriment to general interacivity.
> > I can now reproduce some loss of interactive feel with O17.
> >Something specific for the spin on waiters is required that doesn't affect
> >general performance. The fact that I can reproduce the same starvation in
> >vanilla 2.6.0-test3 but to a lesser extent means this is an intrinsic
> > problem that needs a specific solution.
> I can see only one possible answer to this - never allow a normal task to
> hold the cpu for long stretches (define) while there are other tasks
> runnable. (see attachment)
I assume you mean the strace ? That was the only attachment, and it just looks
like shiploads of schedule() from the get time of day. Yes?
> I think the _easiest_ fix for this particular starvation (without tossing
> baby out with bath water;) is to try to "down-shift" in schedule() when
> next == prev. This you can do very cheaply with a find_next_bit(). That
> won't help the case where there are multiple tasks involved, but should fix
> the most common case for dirt cheap. (another simple alternative is to
> globally "down-shift" periodically)
Err funny you should say that; that's what O17 did. But it hurt because it
would never allow a task that used a full timeslice to be next==prev. The
less I throttled that, the less effective the antistarvation was. However
this is clearly a problem without using up full timeslices. I originally
thought they weren't trying to schedule lots because of the drop in ctx
during starvation but I forgot that rescheduling the same task doesnt count
as a ctx.
Also I recall that winegames got much better in O10 when everything was
charged at least one jiffy (pre nanosecond timing) suggesting those that were
waking up for minute amounts of time repeatedly were being penalised; thus
taking out the possibility of the starving task staying high priority for
> The most generally effective form of the "down-shift" anti-starvation
> tactic that I've tried, is to periodically check the head of all queues
> below current position (can do very quickly), and actively select the
> oldest task who hasn't run since some defined deadline. Queues are
> serviced based upon priority most of the time, and based upon age some of
> the time.
Hmm also sounds fudgy.