4.2BSD VAX: data/stack segments > 6Mb

[jdb at mordor.UUCP]

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 at MIT-XX in <13280 at 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 at mordor.ARPA [jdb at s1-c]	(415) 422-0758
  UUCP: ...!ucbvax!dual!mordor!jdb 	...!decvax!decwrl!mordor!jdb