[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [Xen-devel] [RFC] Replacing Xen's xmalloc engine and(?) API
> >> 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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |