DragonFly kernel List (threaded) for 2003-08
Getting rid of kmem_map
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