WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>, "Xen-Devel (E-mail)" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-devel] [RFC] Replacing Xen's xmalloc engine and(?) API
From: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>
Date: Sun, 12 Oct 2008 10:31:39 -0700 (PDT)
Cc: Diwaker Gupta <dgupta@xxxxxxxxxxx>, nitingupta910@xxxxxxxxx, kurt.hackel@xxxxxxxxxx
Delivery-date: Sun, 12 Oct 2008 10:32:21 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C517E8AE.1E193%keir.fraser@xxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
> >> 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

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