Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!uunet!tut.cis.ohio-state.edu!sei.cmu.edu!fs7.ece.cmu.edu!o.gp.cs.cmu.edu!pt.cs.cmu.edu!spice.cs.cmu.edu!af
From: af@spice.cs.cmu.edu (Alessandro Forin)
Newsgroups: comp.protocols.nfs
Subject: Re: disk queues of length zero..... or scaling up hurts
Summary: use a better VM system
Message-ID: <12254@pt.cs.cmu.edu>
Date: 6 Mar 91 16:49:04 GMT
References: <PCG.91Mar4210505@aberdb.cs.aber.ac.uk> <743@spim.mips.COM>
Organization: Carnegie-Mellon University, CS/RI
Lines: 39

In article <743@spim.mips.COM>, mash@mips.com (John Mashey) writes:
> In article <1991Mar6.003008.9131@bellcore.bellcore.com> mo@bellcore.com (Michael O'Dell) writes:
> >For example -
> 
> >	Assume you memory map and create large file on a machine with lots
> >	of free memory.  Say you write 50 megabytes.  You now close
> >	the file and hence ask for it to really go to disk.
> >	WHAM! 50 megabytes goes on the disk queue.  Yes this does happen,
> >	and boy, is the poor dweeb at some other terminal who just
> >	typed "ls" on the same filesystem really screwed.
> 
> Actually, mo is understating the case ... it can get even worse...
> Suppose you permit the disk cache to occupy up to, or close to 100%
> of memory outside the kernel.
> Then, all of a sudden, not only is there a giant disk queue for
> a specific disk [which makes ls not only on the filesystem, but on the
> disk, not so good], BUT you have a gaint bunch of dirty pages in memory,
> and if you're not careful, you may have thrown away clean pages of
> read-only code to get there.
> 

While I agree with the point made here that disk throughput should
scale up with the rest of the system throughput and it isn't, IMHO
that using an obsolete VM system for reference is not a good starting
point.

I hate to sound like a sales pitch, but it is a fact that with Mach'
external memory management facilities one has much better leverage
on these issues.  Just think of it as a big cache with user-mode
instructions to manage it ;-))

As to what I would do to the disk subsystem... I'd probably concentrate
on making large xfers very fast, with gather-dma for writes 'course.
A bit more intelligence on the disk controller seems mandatory.

Yes, this is partly futuristic given the current software, but that is
where I think we are going.

sandro-