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 ]
