>From my note I wrote last year: - There's a need to initialize pool(9) and vmem(9) subsystems very early - just after BSS is initialized and C code is run. So that MD init code can use vmem(9) as a generic space allocator to manage MD resources.
To do this, we need a new MI function (say mi_bootstrap()) to be called at the entry of initxxx(). This new mi_bootstrap() initializes mutex, cv, and pool. All of these don't allocate memory. - To bootstrap vmem(9), we need a bootstrap poolpage because vmem(9) relies on pool for boundary tags. This part is partially done in the yamt-kmem branch. I don't fully understand the problems you explain, but I agree that the current bootstrap code order has some room to be improved. Keep good work. :) Masao On Sun, Jan 16, 2011 at 03:35:17PM +0100, Lars Heidieker wrote: > 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 ] -- Masao Uebayashi / Tombi Inc. / Tel: +81-90-9141-4635
