Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!cbatt!ucbvax!CERNVM.BITNET!JCV From: JCV@CERNVM.BITNET.UUCP Newsgroups: mod.computers.vax Subject: Re: Sizes of look-aside lists Message-ID: <8701300258.AA22729@ucbvax.Berkeley.EDU> Date: Thu, 29-Jan-87 22:27:30 EST Article-I.D.: ucbvax.8701300258.AA22729 Posted: Thu Jan 29 22:27:30 1987 Date-Received: Sat, 31-Jan-87 01:48:03 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 71 Approved: info-vax@sri-kl.arpa 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!