lkml.org 
[lkml]   [2006]   [Jan]   [6]   [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 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 [unhandled content-type:application/octet-stream]
\
 
 \ /
  Last update: 2006-01-06 08:42    [W:0.089 / U:1.116 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site