From: Bernd Eckenfels <ecki@calista.eckenfels.6bone.ka-ip.net>
To: linux-kernel@vger.kernel.org
Subject: Re: Interactivity improvements
In-Reply-To: <20030807204817.GZ32488@holomorphy.com>
User-Agent: tin/1.5.19-20030610 ("Darts") (UNIX) (Linux/2.4.20-xfs (i686))
Message-Id: <E19ksHM-0003Xl-00@calista.inka.de>
Date: Thu, 07 Aug 2003 23:26:36 +0200
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1587
Lines: 36

In article <20030807204817.GZ32488@holomorphy.com> you wrote:
> On Thu, Aug 07, 2003 at 04:24:18PM +0100, Richard Curnow wrote:
>> What about compilers chewing on source files coming in over NFS rather
>> than resident on local block devices?  The network waits need to be
>> broken out into NFS versus other, or UDP versus TCP or something.  e.g.
>> waits due to the user not having typed anything yet, or moved the mouse,
>> are going to be on TCP connections.
> 
> I'd be interested in whatever you come up with for this, as I use NFSS
> a lot.

Well, it might be easy to separate user mode blocking in filesystem
operations as opposed to usermode sleeping on file descriptors on a file
system type base. 

But maybe we do not need to differentiate anyway, perhaps we can somehow
detect blocking reads which stress the hardware, vs. blocking reads which
actually lowers the load. Perhaps we need a fd flag for that, where FDs
pointing to fifo, socket and pipes will be free, and FDs pointing to some
devices (e.g. not tty) and files will be tainted and get penalty on
blocking.

Another optimisation would be to only penalt a blocking process if there is
more than one, to avoid renicing processes on otherwise unloaded but slow
systems.

Greetings
Bernd
-- 
eckes privat - http://www.eckes.org/
Project Freefire - http://www.freefire.org/
-
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/