>This just doesn't seem right to me, any of it.  If the user chooses to
>override certain values like bufpages, nbuf, nkpde, or SHMMAX, we ought to
>adjust the maximum sizes of the larger structures to accomodate him.  Is there
>some hideously complicated reason we can't add up the sizes, and _then_ set
>VM_MAX_KERNEL_ADDRESS?  I realize that this would be a reasonably substantial
>reworking of locore, but it's mostly formulaic, right?

>A news server with 128MB of memory and 16GB of disk is going to be an awful
>lot happier with a 64MB buffer cache and 3GB of available user VA space than
>with a tiny buffer cache and more space available for user code.

I see what _may_ be a similar problem with kernel profiling.

When I configure a medium-memory machine -- 64Mbytes -- with pcvt,
a generous amount of 4K mbuf clusters, and kernel profiling,
the machine panics while going multi-user:


options		MCLSHIFT=12		# 4-Kbyte mbuf clusters
options 	NMBCLUSTERS=512	# lots of mbufs for a fast interfaces
options 	NKMEMCLUSTERS="(8 * 1024 * 1024 / CLBYTES)" # lots of kernel VM too



When configured with -p, the default profiling resolution causes such
a kernel to panic when going multi-user. Halving the profiling
resoultion (and thus the space needed for pc-samples) works, but only
if I configure pccons instead of pcvt.

Is there something else static I also need to increase, 
to stop the kernel from panicking due to kernel malloc() failing?
If so, what is it?

I'm not sure what's going on here. But the static kernel VM sizing
does seem very fragile.  Worse, the existing config tools aren't
flexible enough to override some of the relevant parameters
(NKMEMCLUSTERS) safely.  (the parens in NKMMEMCLUSTERS break
kernel-library makes, I have to build them by hand.)

I expect there's something obvious I'm missing here, but what is it?

--Jonathan