Re: [PATCH] sched: Fix adverse effects of NFS client on interactive response

[Mike Galbraith <efault@gmx.de>]

At 12:11 PM 1/7/2006 +1100, Peter Williams wrote:

>Is that patch complete?  (This is all I got.)

Yes.

>--- linux-2.6.15/kernel/sched.c.org     Fri Jan  6 08:44:09 2006
>+++ linux-2.6.15/kernel/sched.c Fri Jan  6 08:51:03 2006
>@@ -1353,7 +1353,7 @@
>
>  out_activate:
>  #endif /* CONFIG_SMP */
>-       if (old_state == TASK_UNINTERRUPTIBLE) {
>+       if (old_state & TASK_UNINTERRUPTIBLE) {
>                 rq->nr_uninterruptible--;
>                 /*
>                 * Tasks on involuntary sleep don't earn
>@@ -3010,7 +3010,7 @@
>                                 unlikely(signal_pending(prev))))
>                         prev->state = TASK_RUNNING;
>                 else {
>-                       if (prev->state == TASK_UNINTERRUPTIBLE)
>+                       if (prev->state & TASK_UNINTERRUPTIBLE)
>                                 rq->nr_uninterruptible++;
>                         deactivate_task(prev, rq);
>                 }
>
>In the absence of any use of TASK_NONINTERACTIVE in conjunction with 
>TASK_UNINTERRUPTIBLE it will have no effect.

Exactly.  It's only life insurance.

>   Personally, I think that all TASK_UNINTERRUPTIBLE sleeps should be 
> treated as non interactive rather than just be heavily discounted (and 
> that TASK_NONINTERACTIVE shouldn't be needed in conjunction with it) BUT 
> I may be wrong especially w.r.t. media streamers such as audio and video 
> players and the mechanisms they use to do sleeps between cpu bursts.

Try it, you won't like it.  When I first examined sleep_avg woes, my 
reaction was to nuke uninterruptible sleep too... boy did that ever _suck_ :)

I'm trying to think of ways to quell the nasty side of sleep_avg without 
destroying the good.  One method I've tinkered with in the past with 
encouraging results is to compute a weighted slice_avg, which is a measure 
of how long it takes you to use your slice, and scale it to match 
MAX_SLEEPAVG for easy comparison.  A possible use thereof:  In order to be 
classified interactive, you need the sleep_avg, but that's not enough... 
you also have to have a record of sharing the cpu. When your slice_avg 
degrades enough as you burn cpu, you no longer get to loop in the active 
queue.  Being relegated to the expired array though will improve your 
slice_avg and let you regain your status.  Your priority remains, so you 
can still preempt, but you become mortal and have to share.  When there is 
a large disparity between sleep_avg and slice_avg, it can be used as a 
general purpose throttle to trigger TASK_NONINTERACTIVE flagging in 
schedule() as negative feedback for the ill behaved.  Thoughts?

         -Mike