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

[Keir Fraser <keir.fraser@xxxxxxxxxxxxx>]

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

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

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.

 -- Keir



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