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

From: Trond Myklebust <trond.myklebust@fys.uio.no>
To: Kyle Moffett <mrmacman_g4@mac.com>
Cc: Peter Williams <pwil3058@bigpond.net.au>,
	Ingo Molnar <mingo@elte.hu>, Con Kolivas <kernel@kolivas.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] sched: Fix adverse effects of NFS client	on	interactive response
Date: Wed, 21 Dec 2005 08:40:53 -0500	[thread overview]
Message-ID: <1135172453.7958.26.camel@lade.trondhjem.org> (raw)
In-Reply-To: <962C9716-6F84-477B-8B2A-FA771C21CDE8@mac.com>

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