>> #define MAX_KMAP	10
>> #if 0
>> #define MAX_KMAPENT	500
>> #else
>> #define MAX_KMAPENT	1000  /* XXXCDC: no crash */
>> #endif

>Yes, that worked out OK.  We still killed the machine, but rather
>than a panic at ~250 processes, it was up to ~450.  I am going to
>double the constant again (to 2000) just to make sure we're OK when
>we start our tests.

right (the 'XXXCDC' comment is mine, btw).   the VM system in 
1.3.2 allocates two or so kernel map entries per process due to 
the unfortunate way it wires and unwires a process' u-area.  
that's why doubling the MAX_KMAPENT value allows you to have 
almost twice as many processes running at once.   as you've 
discovered, when you run out of kernel map entries the system 
panics.

i changed the way the u-area is handled in UVM, so this shouldn't
be a problem in -current (with UVM).   i eventually plan to modify
UVM to dynamically allocate kernel map entries kind of like how
freebsd and openbsd do it, but i haven't gotten to it yet.  once
that is done, MAX_KMAPENT (and that panic) can be nuked.


note that there is no need to adjust MAX_KMAP if your system boots
properly.   kernel maps are only allocated at system startup time.
i have already gotten rid of MAX_KMAP in UVM by changing the submap
interface.

chuck