Messages in this thread | | | Date | Sat, 07 Jan 2006 06:27:04 +0100 | From | Mike Galbraith <> | Subject | Re: [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/
| |