WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>, xen-devel mailing list <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-devel] [PATCH][RFC] sub-page anonymous domain memory allocator
From: Daniel Magenheimer <dan.magenheimer@xxxxxxxxxx>
Date: Fri, 29 Aug 2008 12:46:02 -0700 (PDT)
Cc:
Delivery-date: Fri, 29 Aug 2008 12:47:28 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C4DDFC13.1CA2C%keir.fraser@xxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxx]
> 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@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
> > http://lists.xensource.com/xen-devel
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
>

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>