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

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

On Wed, 2005-12-21 at 08:36 -0500, Kyle Moffett wrote:
> On Dec 21, 2005, at 08:21, Trond Myklebust wrote:
> > ...and if you stick in a faster server?...
> >
> > There is _NO_ fundamental difference between NFS and a local  
> > filesystem that warrants marking one as "interactive" and the other  
> > as "noninteractive". What you are basically saying is that all I/O  
> > should be marked as TASK_NONINTERACTIVE.
> 
> Uhh, what part of disk/NFS/filesystem access is "interactive"?  Which  
> of those sleeps directly involve responding to user-interface  
> events?  _That_ is the whole point of the interactivity bonus, and  
> precisely why Ingo introduced TASK_NONINTERACTIVE sleeps; so that  
> processes that are not being useful for interactivity could be moved  
> away from TASK_NONINTERRUPTABLE, with the end result that the X- 
> server could be run at priority 0 without harming interactivity, even  
> during heavy *disk*, *NFS*, and *network* activity.  Admittedly, that  
> may not be what some people want, but they're welcome to turn off the  
> interactivity bonuses via some file in /proc (sorry, don't remember  
> which at the moment).

Then have io_schedule() automatically set that flag, and convert NFS to
use io_schedule(), or something along those lines. I don't want a bunch
of RT-specific flags littering the NFS/RPC code.

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