[lkml]   [2003]   [Aug]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] O17int
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 [unhandled content-type:application/octet-stream]
 \ /
  Last update: 2005-03-22 13:47    [W:0.258 / U:1.340 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site