[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.