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

[Trond Myklebust]

On Fri, 2005-12-23 at 14:06 +1100, Peter Williams wrote:
> > 
> > As far as a filesystem is concerned, there should be 2 scheduling
> > states: running and sleeping. Any scheduling policy beyond that belongs
> > in kernel/*.
> 
> Actually there are currently two kinds of sleep: interruptible and 
> uninterruptible.  This just adds a variation to one of these, 
> interruptible, that says even though I'm interruptible I'm not 
> interactive (i.e. I'm not waiting for human intervention via a key 
> press, mouse action, etc. to initiate the interrupt).  This helps the 
> scheduler to decide whether the task involved is an interactive one or 
> not which in turn improves users' interactive experiences by ensuring 
> snappy responses to keyboard and mouse actions even when the system is 
> heavily loaded.

No! This is not the same thing at all.

You are asking the coder to provide a policy judgement as to whether or
not the users might care.

As far as I'm concerned, other users' MP3 player, X processes, and
keyboard response times can rot in hell whenever I'm busy writing out
data at full blast. I don't give a rats arse about user interactivity,
because my priority is to see the batch jobs complete.

However on another machine, the local administrator may have a different
opinion. That sort of difference in opinion is precisely why we do not
put this sort of policy in the filesystem code but leave it all in the
scheduler code where all the bits and pieces can (hopefully) be treated
consistently as a single policy, and where the user can be given tools
in order to tweak the policy.

TASK_NONINTERACTIVE is basically a piss-poor interface because it moves
the policy into the lower level code where the user has less control.

> There are probably many interruptible sleeps in the kernel that should 
> be marked as non interactive but for most of them it doesn't matter 
> because the duration of the sleep is so short that being mislabelled 
> doesn't materially effect the decision re whether a task is interactive 
> or not.  However, for reasons not related to the quality or efficiency 
> of the code, NFS interruptible sleeps do not fall into that category as 
> they can be quite long due to server load or network congestion.  (N.B. 
> the size of delays that can be significant is quite small i.e. much less 
> than the size of a normal time slice.)
> 
> An alternative to using TASK_NONINTERACTIVE to mark non interactive 
> interruptible sleeps that are significant (probably a small number) 
> would be to go in the other direction and treat all interruptible sleeps 
> as being non interactive and then labelling all the ones that are 
> interactive as such.  Although this would result in no changes being 
> made to the NFS code, I'm pretty sure that this option would involve a 
> great deal more code changes elsewhere as all the places where genuine 
> interactive sleeping were identified and labelled.

That is exactly the same rotten idea, just implemented differently. You
are still asking coders to guess as to what the scheduling policy should
be instead of letting the user decide.

  Trond

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