Thx-1138@SRI-KL.ARPA:WILLIAMS@EDWARDS-2060.ARPA (01/30/87)
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 -------
JCV@CERNVM.BITNET.UUCP (01/30/87)
I disagree with Kevin Oberman's and Mark Johnson's observations on the size of the nonpaged pool look-aside lists. I can see no reason why they should be any larger than the number you really require and a number of reasons to make them as small as possible (even making the ...V parameters as small as possible). First, some remarks about the actual mechanisms: 1. Each look-aside list and nonpaged pool (which are handled seperately) are allocated system virtual memory (PTEs only) up to their m a x i m u m size at boot time. Therefore, the lists and pool are virtually contiguous (and only that is important); no space is wasted on expansion. The unused difference between the actual size and the maximum size wastes a (small) amount of memory permanently, however: The system PTE, which must always be resident, occupies 4 bytes per unused page. So, if you're not using, e.g., 300 LRPs of 1584 bytes each, this requires about 475 virtual pages and thus wastes about 4 pages of memory permanently. 2. Each list and nonpaged pool are allocated permanent memory (always resident and not useable by other programs) up to the size indicated by the ...COUNT and NPAGEDYN parameters, resp. If these sizes are too large (and AUTOGEN always sets them to some astronomic size, so you are forced to buy more memory to get sensible performance out of your machine), the unused space is wasted forever. If you use the above (not too unrealistic) example, you would increase the space required by the system (which is reported by SHOW MEMORY in the last line) by those 475 pages! 3. If expansion is necessary, VMS will steal a page from the free list, make the appropriate entry in the system page table valid and format the new memory as necessary. This will waste the previously allocated PFN database for that page, which is 18 bytes (22 bytes on machines with more than 32 MB of memory). This is only for those pages added when pool is expanded, as the space allocated during booting is never accounted for in the PFN database. Note that the actual operation of increasing the list is only done once and is quite fast (no I/O, for instance). 4. As a side remark, the 'wasted' space from 2. and 3. are not necessarily really wasted, as both the size of the system page table and the PFN database are calculated with a certain 'fuzziness' to avoid iterative and potentially numerically unstable calculations at boot time. For large excesses, you however will be wasting memory. 5. From the allocation point of view, I can see no difference whether the space was allocated from the beginning or added later. For the look-aside lists, this involves only a REMQUE operation; for non-paged pool, the list of free blocks has to be scanned, but I can't see how a larger initial pool size would reduce the amount of fragmentation (which makes the allocation slow). Thus, I simply cannot understand why a VMS developper would claim that having at least 100 000 bytes free in non-paged pool is beneficial. If one of them is listening, could you please comment? My conclusions from the above have always been to set (not use ADD_) the values of ...COUNT and NAPGEDYN to some value somewhat smaller than the actual size in MODPARAMS.DAT and reboot after AUTOGENing. After a few days of normal operations (not only a weekend!), look at the actual numbers and set the final values to slightly less than the actual ones. One can also reduce the ...COUNTV parameters, as AUTOGEN uses a fixed multiplication factor quite unrealistic especially on machines with large amounts of memory - if you're using 10000 SRPs or IRPs, you're in a fix anyway, and once they're freed, you might just as well reboot to reclaim the wasted memory!
dolson@ADA20.ISI.EDU.UUCP (01/31/87)
>From: JCV@CERNVM.BITNET >Subject: Re: Sizes of look-aside lists > >I disagree with Kevin Oberman's and Mark Johnson's observations >on the size of the nonpaged pool look-aside lists. I can see no >reason why they should be any larger than the number you really >require and a number of reasons to make them as small as possible >(even making the ...V parameters as small as possible). > [...] > >3. If expansion is necessary, VMS will steal a page from the free list, > make the appropriate entry in the system page table valid and > format the new memory as necessary. This will waste the previously > allocated PFN database for that page, which is 18 bytes (22 bytes > on machines with more than 32 MB of memory). This is only for those > pages added when pool is expanded, as the space allocated during > booting is never accounted for in the PFN database. > Note that the actual operation of increasing the list is only done > once and is quite fast (no I/O, for instance). Well...there is room for disagreement here. "If expansion is necessary" then your machine is presumably loaded, all its request packets of one sort or another are in use, and its the worst possible time for VMS to steal a page from the free list; its already behind on doing the work its supposed to be at, or it wouldn't have all those request packets waiting around holding temporary data. I would NOT agree that this is "quite fast", because you are imposing additional system overhead at exactly the worst time, when your cpu cycles are in shortest suppply. If it HAS to happen, I'd rather arrange pool space at startup, than choose to rearrange it when it runs out... Doug Olson Project Manager AFCMD, Kirtland AFB, NM -------
MHJohnson@HI-MULTICS.ARPA.UUCP (02/03/87)
I'll have to take back what I said about fragmentation, I reread the VMS Internals book and it does indicate the method described previously. Perhaps I am remembering something that used to be done in VMS a long time ago (long live VMS v1.5...). However, I still recommend getting the values for the (S I L)RP's as close to the peak usage as possible to minimize the thrashing that occurs when the system gets loaded. I also recommend buying more memory to reduce paging in addition to other fixes. I believe that 8 mbytes is not enough for a 780 (or 8200) class machine with any real load. We run quite comfortably w/ 16 mbytes on a 785 and uncomfortably w/ 8 mbytes on an 8200. I should find out soon how 32 mbytes is on an 8700 but I doubt it will be enough. There are plenty of good third party memory boards out there (even for the BI!) and I have yet to be dissappointed with any we have bought (Emulex, Clearpoint, & Trendata). They are worth every dollar. --Mark <MHJohnson @ HI-MULTICS.ARPA> PS: when you go buy extra memory, be sure to increase several system parameters relating to your working set sizes, peak virtual pages, page file quotas (increase page & swap files too...) and the related user authorization values to get best use of the extra memory. By doing this you get the best results over a wide range of loads with the extra ememory.
sasaki@HARVARD.HARVARD.EDU.UUCP (02/08/87)
Pool fragmentation can be a problem with buffered i/o operations. If the pool is fragmented and you need to allocate a page, then you have to search longer to find that page. Usually the allocation comes out of the lookaside lists, but if the pre-allocated list is used up, the generic pool searching is done. ---------------- Marty Sasaki uucp: harvard!sasaki Ziff Davis Technical Information Co. arpa: sasaki@harvard.harvard.edu 80 Blanchard Road bitnet: sasaki@harvunxh Burlington, MA 01803 phone: 617-273-5500