From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: [RFC] Replacing Xen's xmalloc engine and(?) API Date: Sun, 12 Oct 2008 11:25:34 +0100 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Dan Magenheimer , "Xen-Devel (E-mail)" Cc: Diwaker Gupta , nitingupta910@gmail.com, kurt.hackel@oracle.com List-Id: xen-devel@lists.xenproject.org On 12/10/08 10:16, "Keir Fraser" wrote: > On 11/10/08 22:44, "Dan Magenheimer" 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