> The /sys/arch/vax/include/vmparam.h file defines the following constants
> which affect some of the resource limit setting on the NetBSD/vax port:
> 
>   #define MAXTSIZ         (8*1024*1024)           /* max text size */
>   #define DFLDSIZ         (32*1024*1024)          /* initial data size limit */
>   #define MAXDSIZ         (64*1024*1024)          /* max data size */
>   #define DFLSSIZ         (512*1024)              /* initial stack size limit */
>   #define MAXSSIZ         (8*1024*1024)           /* max stack size */
> 
> I know that with early version of NetBSD/vax, raising these values could
> have detrimental effects on the page tables, causing them to balloon in
> size.  With the 1.6 release (at least?), there have been some changes to
> the VAX port's VM system to remedy that problem.
> 
Quick C explanation of the calculation:

#define PROCPTSIZE ((MAXTSIZ + MAXDSIZ + MAXSSIZ + MMAPSPACE) / VAX_NBPG)
usrptsize = PROCPTSIZE * maxproc;

The above gives the number of PTEs needed in the kernel page table for
keeping the user page table. Having maxproc == 128 will result in a need for
((8*1024*1024 + 64*1024*1024 + 8*1024*1024 + 8*1024*1024)/512) * 128 ptes,
which is 23068672*sizeof(struxt pte) == 92274688 or 88MB kernel virtual
memory. This in turn allocates 92274688/(VAX_NBPG/sizeof(struxt pte)) bytes
or 704KB of physical memory, which is about 20% of available memory on a 4MB
machine. 

The main problem is that mmap() of memory is done above the data segment,
so all running processes are likely to use (almost) its full page table.
Increasing MAXDSIZ to the double would almost double the amount of physical
memory required.

Someone was working at moving the mmap area to just below the user stack
instead, if that could be done this would not be an issue anymore.

-- Ragge