Getting rid of kmem_map

[Matthew Dillon]

    As I begin work on the slab allocator I have taken a good look at the
    use of kmem_map and kernel_map.  kmem_map basically exists to avoid
    deadlocks between interrupts trying to allocate memory (e.g. through
    zget()) and the mainline system.

    But all of our 'slow' interrupts and software interrupts are now threads,
    and they can theoretically block on kernel_map without creating an
    issue other then high interrupt latency, which we can address elsewhere.

    I will have to review our 'fast' interrupts (basically the clock interrupts
    and maybe the serial interrupts), but I don't think these interrupts 
    allocate any memory.  

    I believe this means that we can do away with kmem_map in relative
    safety.  Being able to do so will significantly reduce the number of
    memory related special cases in the system.  In particular the entire
    kernel_map will become available for allocations by malloc/zalloc/slab.

    If I can successfully do this tonight and tomorrow I think I may spend
    the rest of the week converting malloc and zalloc entirely over to 
    the slab allocator.  zalloc in particular has always been a thorn in our
    side due to the type-stable nature of zfree(), but in reality there are
    only a few places where the type stability is actually necessary (like
    the proc structure) and those could probably be converted to simple
    per-cpu freelists.

						-Matt