Re: kernel memory allocators

[Masao Uebayashi <uebayasi%tombi.co.jp@localhost>]

>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