Path: utzoo!utgpu!utstat!jarvis.csri.toronto.edu!mailrus!cornell!uw-beaver!rice!sun-spots-request
From: brent%sprite.Berkeley.EDU@ginger.berkeley.edu (Brent Welch)
Newsgroups: comp.sys.sun
Subject: Re: filesystem activity causes 4.0 to bog down
Message-ID: <8902221723.AA729380@sprite.Berkeley.EDU>
Date: 4 Mar 89 00:43:40 GMT
Sender: usenet@rice.edu
Organization: Sun-Spots
Lines: 24
Approved: Sun-Spots@rice.edu
Original-Date: Wed, 22 Feb 89 09:23:46 PST
X-Sun-Spots-Digest: Volume 7, Issue 180, message 1 of 12

Yup, SunOS 4.0 uses mapped files.  If you are not careful in the
implementation you can swap out processes in favor of files, especially
during copy of a large file.  By mapping the file into your address space
you end up walking through memory, paging away.  There are heuristics that
you can build into your VM system to account for this.  I'm not sure how
mature the 4.0 implementation is, however, and if they have done anything
along these lines, yet.

In Sprite we have potentially the same problem, not because we use mapped
files (which we don't) but because we allow the file system cache to grow
upon demand.  VM and FS negotiate over free pages, and they compare LRU
times when a page needs to be replaced.  We ended up adding a bias against
the file system so that recently touched VM pages are not discarded in
favor of new FS pages.  By setting the bias to 600 seconds, for example,
any VM page touched within the last 10 minutes won't be pitched to make
room for a FS page.  Instead, FS has to recycle one of its own pages.
Mike Nelson ran some benchmarks pitting a large sort against a large gdb
process and found that *both* processes ran faster with a bias against FS.
The reduced paging activity actually helped the sort as well as the
process with the large VM image.

	Brent Welch
	University of California, Berkeley
	brent%sprite@ginger.Berkeley.EDU