RE: [RFC] Replacing Xen's xmalloc engine and(?) API

[Dan Magenheimer <dan.magenheimer@oracle.com>]

Hi Nitin --

Excellent!  Your xvMalloc looks even better!  I'll read the
code and try it (tomorrow).

Keir, is a "GNU Lesser GPL Version 3" license OK for Xen?

Thanks,
Dan

> -----Original Message-----
> From: Nitin Gupta [mailto:nitingupta910@gmail.com]
> Sent: Sunday, October 12, 2008 11:45 AM
> To: Dan Magenheimer
> Cc: Keir Fraser; Xen-Devel (E-mail); Diwaker Gupta; Kurt Hackel
> Subject: Re: [Xen-devel] [RFC] Replacing Xen's xmalloc engine 
> and(?) API
> 
> 
> On Sun, Oct 12, 2008 at 11:01 PM, Dan Magenheimer
> <dan.magenheimer@oracle.com> wrote:
> >
> > I'm no slab/slub expert but I think the interface only works
> > well with fixed-size objects and when several of the fixed-size
> > objects can be crammed into a single page.  I have a large set
> > of objects that are essentially random in size (but all less
> > than or equal to a page).
> >
> 
> Using slab for your use case, which requires lot of allocations for
> near page-sized objects, is really bad idea. For memory compression
> project (compcache) I had very similar requirement. So, I tested
> kmalloc which uses slabs of various sizes to allocate various sizes.
> As expected its space efficiency was horrible. At least for compcache
> workload it used ~40% more memory than TLSF. Please refer:
> http://code.google.com/p/compcache/wiki/AllocatorsComparison
> 
> Regarding non-standard TLSF interface, it should be quite simple to
> have wrappers around TLSF to have standard malloc/free API.
> 
> Also I recently completed draft implementation of a new allocator -
> xvMalloc (based on TLSF) that is specifically suited for allocation
> behavior of compcache (I think "difference engine" project has almost
> same requirements).
> http://code.google.com/p/compcache/wiki/xvMalloc
> 
> Nitin
>