In article <199810230127.SAA06410@smeg.dsg.stanford.edu> you write:
>
>The following patch makes MAP_KMAPENT with the (old) VM system
>autosize enough space for maxusers's worth of processes.
>
>That means making NPROC visible to vm_map.h, but short of
>defparam'ing NPROC, i dont see a way around that.
>
>Anyone object to this? Given the pain its caused 1.3.2 users,
>I'd like to commit it and request a pullup for the 1.3.3 release.
>

As one of the people who brought up the problem, I'd like to see something
like this committed, thus closing (hopefully) my PR kern/6293.

[most of patch deleted]

>  /* XXX: number of kernel maps and entries to statically allocate */
>  #define MAX_KMAP	10
>! 
>! #if !defined(MAX_KMAPENT)
>! #if (50 + (2 * NPROC) > 1000)
>! #define MAX_KMAPENT (50 + (2 * NPROC))
>  #else
>  #define	MAX_KMAPENT	1000  /* XXXCDC: no crash */
>  #endif
>+ #endif	/* !defined MAX_KMAPENT */
>+ 

I did have one (minor) comment:  Why add the complication of limiting
MAX_KMAPENT to 1000 (unless specifically overridden in the kernel config
file) instead of just letting it use NPROC?  Using the default maxusers 32
found in the i386 GENERIC config would yield NPROC of 532 and thus
MAX_KMAPENT of 1114 (without the limit), and using maxusers of 64 (the
highest possible without running into other quirks elsewhere) still yields
an (entirely reasonable for this many users) NPROC of 1044 and MAX_KMAPENT
of 2138.  Either way, I'd rather be safe by having a few more entries
allocated and unused (both memory and swap space are cheap!) than to run
the risk of panicing.

(And if someone kicks NPROC up high enough to cause problems with memory
left after MAX_KMAPENT, they probably need more memory for whatever
they're doing anyway...)

jdarrow

(P.S. PR port-i386/6226... one line... fixes a mistake in a message...
 still open... somebody... anybody?)

--
John Darrow
Computing Services, Wheaton College, Wheaton, IL
John.P.Darrow@wheaton.edu