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

"Axel Dörfler" <[email protected]> Mon, 23 Apr 2007 13:39:32 +0200 CEST
Newsgroups gmane.os.openbeos.kernel.devel
Message-ID <18223973366-BeMail@zon>
Hi Hugo,

"Hugo Santos" <[email protected]> wrote:
> > 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
>   Yes, i know. The malloc backend is there just for testing. In fact
> its not even using malloc but posix_memalign. I believe this backend
> independence is important so we can more easily re-use the same
> infrastructure for user-space applications. I'll add a backend which
> allocates blocks through VM areas to be used inside the kernel.

Sure, as long as it doesn't have an impact on performance, it's the 
best way to go :-)

> > 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
>   Yes, Bonwick's also introduces a very nice resource allocator in 
> his
> 2001 paper which i'm planning to implement as well. We could use it
> for most resources, including FDs, ports, etc.

Just find a better name for it than vmem, then ;-)
I wouldn't mind moving our address space allocation code over to this 
as well, if it can provide the features we need.

> > 4) we don't export any C++ APIs from the kernel; IOW the 
> > implementation
> > will be local to the kernel
>   I would rather have this as standard internal interface sitting in
> libroot which the kernel would use as well. So the C++ API would be
> exposed in libroot, not the kernel (as well as the C interface). I
> really think some of our user-space stuff could benefict from a slab
> allocator, thus my consideration of adding it to libroot.

The kernel doesn't link against libroot anyway, and if that API is 
private and not even used inside libroot, there is little reason to put 
it there (yet).
We could also put it into a separate archive, and let whatever needs it 
link to it for now.

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/