kernel memory allocators

[Lars Heidieker <lars.heidieker%googlemail.com@localhost>]

Hi,

I have got the kmem reworked to be based on the pool allocator
directly with different sized caches, backed by the kmem map making
it's allocations interrupt save, I replaced the malloc with just a
thin wrapper to use the reworked kmem.... system is up and stable.

I just came across the order the pool subsystem is initialized,
pool_init and pool_cache_bootstrap can be called before
pool_subsystem_init is called, which is a bit wired.
It makes it possible to pool_init early during pmap_bootstrap for
example, but allocation from those pools is impossible until
uvm_km_init/kmeminit has run as the allocators do not have any backing
map.
This holds true even if a special allocator is passed to those early
pools as meta data is still allocated from pool_allocator_kmem which
isnt't usable until kmeminit.

For the x86 pmap it's easily possible to move the
pool_init/pool_cache_bootstrap calls from pmap_bootstrap to pmap_init
and have no calls to pool_init before the call to pool_subsystem_init.
This seems possible for other pmaps as well. (I am currently checking this)

If done so this would enable us to init different pool_allocators
during pool_subsystem_init (with different page granualarities
1,2,3,4,5 pages eg) and to choose from those during pool_init to
reduce inner fragmentation.
(Probably splitting the pool_subsystem_init into
pool_subsystem_bootstrap and pool_subsystem_init, with
pool_subsystem_init marking when pool_get is safe)

For those different sizes vmk_caches at the kenrel_map and kmem_map
can be established (Something I have implemented already).

Lars

-- 
Mystische Erklärungen:
Die mystischen Erklärungen gelten für tief;
die Wahrheit ist, dass sie noch nicht einmal oberflächlich sind.
   -- Friedrich Nietzsche
   [ Die Fröhliche Wissenschaft Buch 3, 126 ]