RE: [PATCH][RFC] sub-page anonymous domain memory allocator

[Daniel Magenheimer <dan.magenheimer@oracle.com>]

True, but this way the new anonymous domain sub-page
allocator co-exists with the existing xmalloc mechanism,
which I didn't want to mess with right now.  In the future,
when they are both eating from the same pool of memory,
it won't matter.

Related, any suggestions on how to implement a "low-water mark"
(for any or all of the heaps/nodes)?  I'd like to be
know when memory is running low (and maybe "very low"),
rather than just have it run out.  Especially since
alloc_xenheap_pages gets "chatty".

Thanks,
Dan

> -----Original Message-----
> From: Keir Fraser [mailto:keir.fraser@eu.citrix.com]
> Sent: Friday, August 29, 2008 12:19 PM
> To: Daniel Magenheimer; xen-devel mailing list
> Subject: Re: [Xen-devel] [PATCH][RFC] sub-page anonymous domain memory
> allocator
> 
> 
> You can more simply just have the existing xmalloc interface go at
> alloc_domheap_pages(NULL) on x86/64. That would just need some #ifdef
> abstraction within xmalloc.c.
> 
>  -- Keir
> 
> On 29/8/08 18:12, "Daniel Magenheimer" 
> <dan.magenheimer@oracle.com> wrote:
> 
> > This patch uses some #define-and-Makefile trickery to completely
> > leverage common/xmalloc.c to provide a sub-page memory
> > allocator that takes memory from anonymous domain heap instead
> > of xen heap.  Note that it is useful only on a 64-bit hypervisor.
> > (Some other #define trickery can be used so that 32-bit
> > hypervisor uses xenheap and 64-bit hypervisor uses adheap.)
> > 
> > Keir says that a goal for 3.4 is to combine xen heap and
> > domain heap on 64-bit hypervisors.  This is a step in that
> > direction that I am using today in some work that requires
> > more memory than xenheap can provide (which I'll hopefully
> > post sometime in the next few weeks).
> > 
> > Comments?
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>