lkml.org 
[lkml]   [2006]   [Jan]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] sched: Fix adverse effects of NFS client on interactive response
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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-01-07 06:29    [from the cache]
©2003-2014 Jasper Spaans. Advertise on this site