Re: [Xen-devel] [RFC] Replacing Xen's xmalloc engine and(?) API

[Keir Fraser <keir.fraser@xxxxxxxxxxxxx>]

On 12/10/08 18:44, "Nitin Gupta" <nitingupta910@xxxxxxxxx> 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

Yes, I was just going to reply to Dan's TLSF email to say that my default
plan for improving xmalloc() was going to be to implement a sub-page buddy
allocator or to port SLUB from Linux. Noth of these place metadata in the
page-info structure, but both would end up allocating power-of-two-sized
data blocks for random allocations of xmalloc(). The overheads of this --
for example if many allocations are just over 2048 bytes for example --
could be pretty nasty. I think TLSF sounds quite an intriquing alternative.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel