Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!sdd.hp.com!mips!dimacs.rutgers.edu!rutgers!cbmvax!jesup
From: jesup@cbmvax.commodore.com (Randell Jesup)
Newsgroups: comp.sys.amiga.hardware
Subject: Re: Filesystem Speeds (was Re:  GVP Trade-in)
Keywords: SCSI, GVP
Message-ID: <14736@cbmvax.commodore.com>
Date: 29 Sep 90 22:48:26 GMT
References: <552@DIALix.UUCP> <14069@cbmvax.commodore.com> <558@DIALix.UUCP> <6499@sugar.hackercorp.com> <1159@mpirbn.mpifr-bonn.mpg.de> <14260@cbmvax.commodore.com> <1169@mpirbn.mpifr-bonn.mpg.de>
Reply-To: jesup@cbmvax.commodore.com (Randell Jesup)
Organization: Commodore, West Chester, PA
Lines: 22

In article <1169@mpirbn.mpifr-bonn.mpg.de> p554mve@mpirbn.UUCP (Michael van Elst) writes:
>But even if you think that Unix machines are single-user there are usually
>nonconsecutive disk accesses as program code is (hopefully) demand-loaded and
>larger program systems (should I say X-window servers :-)) will
>often page in and out while the user's program is running.

	That may well be true, though the paging allocation algorithms can
help quite a bit here to improve performance, so that read-ahead doesn't
hurt or helps.  This doesn't have (much) effect on the issue of elevator
algorithms.

	Another personal opinion: if you're getting a lot of real paging (as
opposed to load-paging), then you need more memory.  Note that different
people may define "a lot" in different ways.  I've noted that in every group
I've been in using Suns or whatever, people manage to get enough memory to
avoid signifigant paging in their normal use of the machine.  In the latest
Unixes, this may well mean 8 Meg if you want nice graphical interfaces.

-- 
Randell Jesup, Keeper of AmigaDos, Commodore Engineering.
{uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com  BIX: rjesup  
Common phrase heard at Amiga Devcon '89: "It's in there!"