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

From: Peter Williams
Date: Fri Jan 06 2006 - 20:09:50 EST


Mike Galbraith wrote:
At 10:13 AM 1/6/2006 +1100, Peter Williams wrote:

Mike Galbraith wrote:

At 10:31 PM 1/5/2006 +1100, Peter Williams wrote:

Mike Galbraith wrote:

At 08:51 AM 1/5/2006 +1100, Peter Williams wrote:

I think that some of the harder to understand parts of the scheduler code are actually attempts to overcome the undesirable effects (such as those I've described) of inappropriately identifying tasks as interactive. I think that it would have been better to attempt to fix the inappropriate identifications rather than their effects and I think the prudent use of TASK_NONINTERACTIVE is an important tool for achieving this.



IMHO, that's nothing but a cover for the weaknesses induced by using exclusively sleep time as an information source for the priority calculation. While this heuristic does work pretty darn well, it's easily fooled (intentionally or otherwise). The challenge is to find the right low cost informational component, and to stir it in at O(1).



TASK_NONINTERACTIVE helps in this regard, is no cost in the code where it's used and probably decreases the costs in the scheduler code by enabling some processing to be skipped. If by its judicious use the heuristic is only fed interactive sleep data the heuristics accuracy in identifying interactive tasks should be improved. It may also allow the heuristic to be simplified.


I disagree. You can nip and tuck all the bits of sleep time you want, and it'll just shift the lumpy spots around (btdt).


Yes, but there's a lot of (understandable) reluctance to do any major rework of this part of the scheduler so we're stuck with nips and tucks for the time being. This patch is a zero cost nip and tuck.


Color me skeptical, but nonetheless, it looks to me like the mechanism might need the attached.

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

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


On the subject of nip and tuck, take a look at the little proggy posted in thread [SCHED] wrong priority calc - SIMPLE test case. That testcase was the result of Paolo Ornati looking into a real problem on his system. I just 'fixed' that nanosleep() problem by judicious application of TASK_NONINTERACTIVE to the schedule_timeout(). Sure, it works, but it doesn't look like anything but a bandaid (tourniquet in this case:) to me.

-Mike

Peter
--
Peter Williams pwil3058@xxxxxxxxxxxxxx

"Learning, n. The kind of ignorance distinguishing the studious."
-- Ambrose Bierce
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/