[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



On 12/10/08 10:16, "Keir Fraser" <keir.fraser@xxxxxxxxxxxxx> wrote:

> On 11/10/08 22:44, "Dan Magenheimer" <dan.magenheimer@xxxxxxxxxx> wrote:
> 
>> As a result, I'd like to propose a change to the xmalloc interface
>> to make this issue more explicit:  I'd like to change xmalloc/xfree
>> to FAIL on allocation sizes greater than PAGE_SIZE - DELTA, where
>> DELTA is a defined constant.   Callers that require an allocation
>> larger than that MUST use the page_alloc (and corresponding
>> page_free) interfaces.  In other words, for any dynamic allocation
>> code that needs a dynamically computed size that might exceed a
>> page, the test must be done on the caller-side... and the caller
>> is responsible for remembering whether the subpage allocator or
>> the page-plus allocator was used, and free'ing with the matching
>> subpage-free or page-plus-free routine.  While I'd never propose
>> this unforgiving API for user-land code, I think it isn't unreasonable
>> in a hypervisor.
> 
> This sounds crazy to me. xmalloc() should work like malloc().

For example, why not take Linux's SLUB allocator? The fact it's tried and
tested in a real-world environment not unlike our own is a big advantage to
my mind.

 -- Keir



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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.