On Mon, Dec 12, 2005 at 09:40:01AM +0100, Paul Kranenburg wrote:
> > I see that a mechanism already exists to limit virtual space usage by
> > the buffer cache, buf_setvalimit(), which is used by alpha, mips, sparc
> > and vax.  however, it seems to me that the usage for all but sparc is wrong
> > since it sets the limit to whatever the limit would have been anyway:
> > 
> > 	bufsz = buf_memcalc();
> > 	buf_setvalimit(bufsz);
> > 
> > or maybe this is just supposed to keep people from tuning the limit higher
> > than its original value.  I'm not sure why that would be desirable though.
> > does anyone know why these are here?  if not, I'll remove them.  (the sparc
> > instance actually imposes a smaller limit, so I'll leave that one.)
> 
> 
> This particular sequence was introduced in ports that used to consider
> the amount of virtual memory allocated to the buffer cache (i.e.  `nbuf')
> while setting up their physical memory management module.

sure, but does it do anything useful?  it might have made sense before,
when the buffer cache memory was managed by special purpose code
(pagemove(), etc) but now that the buffer cache memory is allocated
via pools, it shouldn't need special treatment anymore.  or if it does,
then why is memory used by the network code not included in the calculation?
what about all the other users of uvm_km_alloc(), which is what's used
to allocate uareas (which is included in the calculation as well)?

on the alpha at least, pmap_growkernel() should make it unnecessary to
preallocate kernel PTEs for all this stuff.  I guess mips and vax
preallocate everything since they don't implement pmap_growkernel(),
is that right?

-Chuck