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

[Keir Fraser <keir.fraser@xxxxxxxxxxxxx>]

On 12/10/08 18:31, "Dan Magenheimer" <dan.magenheimer@xxxxxxxxxx> wrote:

>> This wastage should be empirically measured by
>> instrumentation and then
>> optimisations made where worthwhile. That is somewhat
>> orthogonal to the
>> issue of what represents a sensible interface to xmalloc(),
>> except to say
>> that I would generally prefer a more sophisticated and
>> efficient mechanism
>> behind a simple interface, rather than punt complexity into
>> callers (by
>> making the costs hidden by the simple interface excessive and hence
>> unusable; or by complicating the interface with weird constraints).
> 
> Fair enough.  I will mimic the xmalloc API then.  However, I *would*
> like to export (via #define in xmalloc.h or function call or something)
> the definition of DELTA (e.g. the xmalloc space overhead) so my
> caller-side code can avoid the wastage.  I never want to accidentally
> xmalloc two pages when heap-alloc'ing one page will do.

A better xmalloc() implementation would allocate the necessary two pages
from alloc_heap_pages() and put the remaining just-less-than-a-page on its
free lists, rather than waste it. Or put the allocation metadata out-of-band
(e.g., in page_info, like SLUB) so that there is no DELTA.

*However*, exposing DELTA for those callers who care about it, given
limitations of current xmalloc() implementation, is a reasonable way to go
as far as I'm concerned.

>> My point in bringing up SLUB is that I assume it's an
>> allocator designed to
>> work reasonably well across a range of allocation-request-size
>> distributions, including those containing requests of size
>> x-pages-minus-a-bit. I'd rather have a more complicated
>> allocator than a
>> more complicated xmalloc() interface.
> 
> 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).

Well, you'd end up using the power-of-two sized caches. And since SLUB
doesn't put metadata in the data pages, the 4096-byte object cache will
serve up true single pages. But yes, this is an aspect I hadn't fully
considered. I'm not wedded to use of SLUB, it was just my arguing stick. :-)

 -- Keir



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