Re: [PATCH] O17int

[Mike Galbraith]

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

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.

Everything I've tried along these lines has a common upside: works, and 
downside: butt ugly :)

        -Mike

Attachment: strace-blender
Description: Binary data