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

[Peter Williams]

Trond Myklebust wrote:
> 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.

No.  It is asking whether the NORMAL interruption of this interruptible 
sleep will be caused by a human user action such as a keystroke or mouse 
action.  For the NFS client the answer to that question is unequivically 
no.  It's not a matter of policy it's a matter of fact.

> 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

It's not policy.  It's a statement of fact about the nature of the sleep 
that is being undertaken.

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

TASK_INTERACTIVE is not about policy.

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

I thought that I said (or at least implied) that.  The difference is 
that we wouldn't be having this conversation.

> You
> are still asking coders to guess as to what the scheduling policy should
> be instead of letting the user decide.

I wish that I could make you understand that that isn't the case. 
You're not being asked to make a policy decision you're being asked to 
make a statement of fact about whether the interruptible sleep is 
interactive or not.  In the cases involved in this patch this question 
is always "no, it's not an interactive" sleep and it can be answered at 
compile time with absolutely no run time overhead incurred.

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/