jdb@mordor.UUCP (05/08/84)
Here at the S-1 Project, LLNL, we are currently running 4.1BSD on one of our VAXes and 4.2BSD on the other. We have a need to run programs with large data and stack segments (> 6Mb). This was no problem in 4.1BSD; I changed "h/dmap.h" and "h/vmparam.h" (as described in the manuals that came with 4.1), recompiled, and it worked. 4.2 is a different matter. I've made it work here, and thought that the experience might be of interest to others. As in 4.1BSD, the constants MAXTSIZ, MAXDSIZ, and MAXSSIZ control the maximum limits that may be set with the rlimit() system call. These constants are now located in "vax/vmparam.h". It seems to be safe to make these "too big" (i.e. larger than the kernel can actually allocate due to the size of the dmap [see below]); the kernel simply returns ENOMEM on a brk() call if it can't map any more memory. (In 4.1BSD if you tried to brk() more memory than it could map, you were rewarded with a panic.) I made MAXDSIZ and MAXSSIZ 30 megabytes. The kernel manages the secondary storage for a virtual address space by allocating pieces of increasing size in the swap area. The mapping is described by "struct dmap" records in the user structure. The first block of each piece is recorded in the array "dm_map". There are NDMAP entries in this array; thus it can keep track of NDMAP fragments. (The first fragment is "dmmin" (32) kilobytes long; each successive fragment is twice as large as the preceeding one until they are "dmmax" (512) kilobytes long. The remainder are all "dmmax" kilobytes. Thus, with NDMAP=16 [as distributed] the structure can map 16+32+64+128+256+512*11 = 6.1Mbytes.) NDMAP and "struct dmap" are defined in "h/dmap.h"; while the initial values of "dmmin" and "dmmax" are defined in "vax/autoconf.c". I increased NDMAP to 64. Unfortunately, increasing NDMAP increases the size of the user structure. Our user structure increased from 1904 to 2160 bytes. This is significant because the user structure and the kernel stack share an area which is UPAGES (512-byte) pages long. The larger user structure now occupies another page, resulting in insufficient space for the kernel stack (one intervening page is used by setredzone() to detect kernel stack overflow). The size of the user+stack area is UPAGES, defined in "vax/param.h". UPAGES must be a multiple of CLSIZE ["vax/vmparam.h"], so I increased it to 10. It is necessary to install the bug fix to "vax/locore.s" described by RWS@MIT-XX in <13280@sri-unix>. This parameterizes the code so that it does not implicitly assume that UPAGES is 8. The system can now be regenerated. Note that "make depend" doesn't catch include files which are included by other include files (e.g. "../vax/param.h" which is included by "../h/param.h"), so it won't properly regenerate "locore.c". It is necessary to delete "assym.s" so that the makefile will regenerate it (with the new definition of UPAGES). Finally (groan), programs which read "/dev/mem" and which include <sys/user.h> will have to be recompiled. This includes things like "ps", "pstat", "w", "adb", "sdb", "dbx", ... -- John Bruner (S-1 Project, Lawrence Livermore National Laboratory) MILNET: jdb@mordor.ARPA [jdb@s1-c] (415) 422-0758 UUCP: ...!ucbvax!dual!mordor!jdb ...!decvax!decwrl!mordor!jdb
dmmartindale@watcgl.UUCP (Dave Martindale) (05/11/84)
Note that when growing the virtual address space, you can double DMMAX if you like - that results in larger maximum-size blocks on the paging device, but then you need only about half as many map entries to handle the larger address space. That's what I did here, and I don't think that UPAGES needed to be grown. Of course, all the other comments about dependencies and recompiling user programs still apply.