On 19 Oct 1998 09:48:08 -0600 
 Chris Jones <cjones@rupert.honors.montana.edu> wrote:

 > What are the reasons for not having these pools dynamically allocated?
 > For as long as I've been using NetBSD (since about 0.9), there have
 > been occasions when I've had to resize these pools for various
 > reasons, and kernel compiles are always necessary.  It's kind of a
 > pain.

Part of the reason for having mb_map and kmem_map is to effectively protect
a region of VM space in interrupt context.  mb_map and kmem_map are allowed
to be accessed during interrupt context, and are thus protected with splimp
when accessed.  If you did that with all of VM space, the system would be
a lot slower, because you'd be blocking interrupts all the time.  Ick.

Given how submaps work, dynamically sizing them is Hard.  (Well, you
could use some heuristic based on how much memory you have, but that's
not necessarily going to tune the way you want.)

Note, the problem with spray and fxp0 IS NOT mb_map filling up.  There
seems to be a bug in the transmit loop in the fxp driver, which I have
seen occasionally but have been unable to reproduce reliably.  I suspect
some race condition which causes the chip to lose the chain of command
descriptors (hence the "device timeout").  You'll get ENOBUFS once the
driver says - "No, you can't queue any more packets right now, I'm at
my self-imposed limit."

Jason R. Thorpe                                       thorpej@nas.nasa.gov
NASA Ames Research Center                            Home: +1 408 866 1912
NAS: M/S 258-5                                       Work: +1 650 604 0935
Moffett Field, CA 94035                             Pager: +1 650 940 5942