> 
> The benefit is not a performance benefit.  kernel_map does not have the 
> same constraints on it that kmem_map does.  kmem_map is the one used by 
> malloc(), and since its size is fixed at boot time, we don't want to 
> put pressure on kmem_map (don't want those dreaded "out of space in 
> kmem_map" panics).
> 
Related to kernel_map I feel an urge to say something (not to you, 
Jason, but in general):

The kernel_map may as well be fixed at a size determined at boot time.
It must be (in some way) possible to know how large the kernel_map
needs to be early in the boot process.

This is a real problem on machines like vax.  For example, 
struct vm_anon for swapping eats by default hundreds of kilobytes
of physical memory just because there is no way to determine in
advance how much will be needed.  (These could be changed to use
the direct-mapped segment, or something, instead, but that's a
separate issue).

Point here: do not assume that the kmem_map is an unlimited amount
of virtual memoer, and if it is going to be used, be sure that the
max memory it will use can be pre-determined.

-- Ragge