[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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |