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] Re: Xenheap disappearance: (was: xen_phys_startfor32b)

To: Jan Beulich <jbeulich@xxxxxxxxxx>, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Subject: RE: [Xen-devel] Re: Xenheap disappearance: (was: xen_phys_startfor32b)
From: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>
Date: Mon, 19 Jan 2009 20:04:00 +0000 (GMT)
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Mon, 19 Jan 2009 12:34:42 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <49744659.76E4.0078.0@xxxxxxxxxx>
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
> as I frequently see systems with completely empty domain heaps.

Really?  Oh, I see we probably have different default paradigms
for memory allocation.  On Oracle VM, dom0 is by default
launched with 256MB and all remaining memory is "free" and
guests are generally launched with memory==maxmem.  As a
result, it is very unusual to have an empty domheap due
to fragmentation.

I expect you are running without dom0_mem unset, thus
using auto-ballooning from dom0 by default.  And probably
either guests are usually launched with memory<<maxmem or
are using disk='file:...' (which results in dom0 filling
up its page cache) or both.  True?

> *must* be accompanied by a tools change in order to be usable

Yes, I see that it would be a must for your different paradigm,
but less important in the one I am accustomed to.

Thanks,
Dan

> >>> Dan Magenheimer <dan.magenheimer@xxxxxxxxxx> 17.01.09 00:16 >>>
> >I'm not sure what you are getting at.  Are you saying that
> >creating a domain takes (big)MB from domheap, then later
> >(little)KB from xenheap, and if we combine domheap and xenheap,
> >the tools might launch a domain when available memory is
> >greater than (big)MB but smaller than (big)MB+(small)KB,
> >and that will result in the tools thinking the domain
> >can launch but it won't?  I suppose that's possible,
> 
> Yes, that's what I'm trying to say. And I think it's rather 
> likely to happen,
> as I frequently see systems with completely empty domain heaps.
> 
> >but exceedingly unlikely.  And I think Keir's plan will
> >have the same problem.  Sounds like a tools bug, not a
> >reason to avoid modernizing Xen memory management.
> 
> No, I wasn't making the point to ask for not doing 
> improvements in Xen -
> in fact, it's been for a long time that I've been raising the 
> scalability issue
> of the limited Xen heap. I was just trying to point out that 
> the Xen change
> *must* be accompanied by a tools change in order to be usable in other
> than development/test environments.
> 
> Jan
> 
> 
> _______________________________________________
> 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