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

[Peter Williams <pwil3058@bigpond.net.au>]

Trond Myklebust wrote:
> On Thu, 2005-12-22 at 19:02 -0500, Kyle Moffett wrote:
>
> > On Dec 22, 2005, at 17:59, Trond Myklebust wrote:
> >
> > > On Fri, 2005-12-23 at 09:33 +1100, Peter Williams wrote:
> > >
> > > > > It still has sod all business being in the NFS code. We don't  
> > > > > touch task scheduling in the filesystem code.
> > > >
> > > > How do you explain the use of the TASK_INTERRUPTIBLE flag then?
> > >
> > > Oh, please...
> > >
> > > TASK_INTERRUPTIBLE is used to set the task to sleep. It has NOTHING  
> > > to do with scheduling.
> >
> > Putting a task to sleep _is_ rescheduling it.  TASK_NONINTERACTIVE  
> > means that you are about to reschedule and are willing to tolerate a  
> > higher wakeup latency.  TASK_INTERRUPTABLE means you are about to  
> > sleep and want to be woken up using the "standard" latency.  If you  
> > do any kind of sleep at all, both are valid, independent of what part  
> > of the kernel you are.  There's a reason that both are TASK_* flags.
>
>
> Tolerance for higher wakeup latencies is a scheduling _policy_ decision.
> Please explain why the hell we should have to deal with that in
> filesystem code?

In order to make good decisions it needs good data.  I don't think that 
it's unreasonable to expect sub systems to help in that regard 
especially when there is no cost involved.  The patch just turns another 
bit on (at compile time) in some integer constants.  No extra space or 
computing resources are required.

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

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.

Peter
--
Peter Williams                                   pwil3058@bigpond.net.au

"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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/