|
|
|
|
|
|
|
|
|
|
xen-devel
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
|
|
|
|
|