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

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

> >> This sounds crazy to me. xmalloc() should work like malloc().
> > 
> > While I agree completely in principle, abstractions can be costly.
> > In this case, the fact that xmalloc(PAGE_SIZE-1) actually uses
> > 2*PAGE_SIZE of space (and fails even if there are lots of free
> > pages but no pair of contiguous pages) is an undocumented 
> consequence
> > of the underlying implementation... which is not entirely
> > unreasonable in user-land but is IMHO questionable in the guts
> > of a hypervisor where memory shouldn't be accidentally wasted.
> > 
> > To date, Xen hasn't focused much on optimizing memory usage but
> > I think that will change over the next year or two.
> 
> 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.

> 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).

Dan