Re: RFC: Slab-o-rama (after Rene's suggestion)

Hi Hugo,

"Hugo Santos" <[email protected]> wrote:
>   After a couple discussions with and suggestions by Travis, i ended
> up writing a very simple allocator for some net_buffer stuff. I wrote
> Saturday and thus never managed to commit it since berlios has been
> down. However, after poking around with it a bit, i moved myself to
> implement a slab allocator, originally to be used by the network
> stack, but which i think could have a wider area of usage. I've 
> mostly
> followed Jeff Bonwick's papers, both his original 94 paper which
> introduces the slab allocator as well as his latest 2001 paper which
> expands the concept to introduce "magazines" and SMP scalability.

Looks like you saved me some work :)

> Please ignore the code style. :-)

Eeek :-)

>   The code is available at: http://fivebits.net/~hugo/haiku/
> 
>   Anyway, this implementation covers most of the Slab and new SMP
> extensions (magazines) bits. There is still stuff to do, including
> dynamic tuning and reacting to memory pressure (this requires VM
> support so i didn't approach it yet).
> 
>   The code is pretty generic so it may be used by applications as 
> well
> (in fact the only backend i've included is a memalign/malloc based
> one). I personally see an interface like this as a candidate to
> libroot, both the C interface which is rather simple and the whole C+
> +
> interface which allows for more complex usage.
> 
>   Let me know of your comments. Most of the code is in Slab.h as my
> original idea was to have a lot of this being inlined. A couple
> examples (still very very simple, just for test) may be found in
> Slab.cpp.

I have a couple of comments:
1) you can't use malloc in the slab allocator at all - it's supposed to 
replace our malloc implementation
2) you can't (easily) use STL in the kernel (no exceptions), also it 
must not use malloc either
3) a hard part of the slab allocator is the backend, as it has to work 
directly on the VM, and yet, it shouldn't collect too many areas
4) we don't export any C++ APIs from the kernel; IOW the implementation 
will be local to the kernel
5) a public userland API shouldn't be added for now, though a private 
one might be nice, especially for replacing the current BMessage 
allocator (and eventually BBufferCache's backend, too).

Bye,
   Axel.


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/