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

[Trond Myklebust <trond.myklebust@fys.uio.no>]

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?

As far as a filesystem is concerned, there should be 2 scheduling
states: running and sleeping. Any scheduling policy beyond that belongs
in kernel/*.

  Trond

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