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

[Mike Galbraith <efault@gmx.de>]

[-- Attachment #1: Type: text/plain, Size: 2367 bytes --]

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.

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 

[-- Attachment #2: sched.c.diff --]
[-- Type: application/octet-stream, Size: 604 bytes --]

--- 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);
 		}