Xen devel - Aug 2008 - [PATCH][RFC] sub-page anonymous domain memory allocator

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

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

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
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel