Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!sri-spam!ames!ucbcad!ucbvax!Thx-1138@SRI-KL.ARPA:WILLIAMS@EDWARDS-2060.ARPA
From: Thx-1138@SRI-KL.ARPA:WILLIAMS@EDWARDS-2060.ARPA
Newsgroups: mod.computers.vax
Subject: Re: Sizes of look-aside lists
Message-ID: <12274873845.19.WILLIAMS@EDWARDS-2060.ARPA>
Date: Thu, 29-Jan-87 17:15:53 EST
Article-I.D.: EDWARDS-.12274873845.19.WILLIAMS
Posted: Thu Jan 29 17:15:53 1987
Date-Received: Sat, 31-Jan-87 05:25:32 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: WILLIAMS@EDWARDS-2060.ARPA
Organization: The ARPA Internet
Lines: 28
Approved: info-vax@sri-kl.arpa



	While I agree in general with JCV@CERNVM.BITNET's remarks about
not "pre-wasting" your nonpaged pool, there is one subtlety that can
occassionally be quite traumatic to the old nervous system.

	Basically, since a lookaside list's expansion comes from the
available "user memory" (free list), you can get into a nasty bind if the
free list itself happens to be short on space.  We used to get into this
problem regularly on our 4MB 11/782, which, when heavily loaded, would have
tremendous memory shortage problems (huge FORTRAN arrays, coupled with large
working set sizes for the users).  Well, just about then we'd start needing
a few LRPs for a DECnet file copy, or worse, some plain old buffer space
for an I/O (LOGINOUT used to trip this limit quite nicely).  The upshot was
that we'd have a slug of a system, processes freezing while they try to
allocate a little pool, and a system that wouldn't allow any nice priv'd type
to log in and see WTF was going on!

	My rule of thumb is to hedge the xRPCOUNT values a little HIGHER
than they run up to during an average amount of uptime.  There are days when
DECnet activity is particularly high, etc., and lookaside extension occurs,
but I figure that that is infrequent enough to make the memory saved for the
almighty users worth the risk...

						-Marc


-------