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] Xen + other stuff?

To: "Gregory Newby" <newby@xxxxxxxx>
Subject: Re: [Xen-devel] Xen + other stuff?
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Thu, 13 Nov 2003 19:24:25 +0000
Cc: Wesley Parish <wes.parish@xxxxxxxxxxxxxxx>, Steven Hand <Steven.Hand@xxxxxxxxxxxx>, Devel Xen <xen-devel@xxxxxxxxxxxxxxxxxxxxx>
Delivery-date: Thu, 13 Nov 2003 19:24:26 +0000
Envelope-to: Steven.Hand@xxxxxxxxxxxx
In-reply-to: Your message of "Thu, 13 Nov 2003 09:33:25 -0900." <20031113183325.GC5846@xxxxxxxxxxxxxxxxxxx>
> Bottom line: get enough RAM for each domain (domain0 + virtuals)
> to share, but the limit will be ~2GB.  When high memory support
> is added, I understand the limit will be 4GB total (since that's
> all the domain0 can address).  So, for a new system, 4GB would
> be the max that Xen can effectively utilize in the immediate future.

We are unlikely to support more than 4GB total memory on x86. Instead
we may port Xen to a 64-bit architecture such as Opteron.

Adding 4GB high-memory support to Linux shouldn't be that hard. Lack
of this support is why currently you can't give a domain more than
800MB. We plan to fix this soon.

> Or maybe I'm wrong - I'm still trying to learn all this stuff.
> How, or whether, Xen is able to utilize swap space is not clear
> to me.  But my advice is to consider everything to operate
> in "real" mode (i.e., no swap at all) -- it's a good way of
> having enough memory, even if swapping is available.

When you specify the memory parameter for a new domain, you are
specifying a precise allocation of real memory. Xen does not ever swap
to disc. However, individual guests can feel free to configure their
own swap file or partition, and performing swapping themselves to/from
their real memory allocation.

 -- Keir