[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Xen-users] Memory bound applications


  • To: "Mathias Waack" <Mathias.Waack@xxxxxxxxxx>, xen-users@xxxxxxxxxxxxxxxxxxx
  • From: "Petersson, Mats" <Mats.Petersson@xxxxxxx>
  • Date: Thu, 20 Apr 2006 14:05:57 +0200
  • Delivery-date: Thu, 20 Apr 2006 05:08:48 -0700
  • List-id: Xen user discussion <xen-users.lists.xensource.com>
  • Thread-index: AcZkb2H89Fess/EMQD22fgoHVytI0gAAgcFA
  • Thread-topic: [Xen-users] Memory bound applications

> -----Original Message-----
> From: xen-users-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:xen-users-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of 
> Mathias Waack
> Sent: 20 April 2006 12:39
> To: xen-users@xxxxxxxxxxxxxxxxxxx
> Subject: [Xen-users] Memory bound applications
> 
> Hello, 
> 
> we're using several test- and development-servers as virtual 
> Xen-machines running on one host. Unfortunately our main 
> application needs much memory. 
> Its not a problem at a first view, because usually only very 
> few instances are running at the same time. But if I 
> understand Xen correctly, its only possible to distribute the 
> physical memory of the machine, not the whole virtual memory 
> of dom0. Let me give an example to explain my problem: 
> 
> The machine has 4GB of physical memory, the application needs 
> about 1GB (mainly used as a kind of shared cache between the 
> instances). Now I would like to have say 4 test and 4 
> development machines, thus using 8 doms. Would be easy to 
> give dom0 just 4+x GB swap, and distribute the resulting 8GB 
> on all machines. Yes I know, if all machines are running the 
> whole system would be very busy swapping, but I'm fairly sure 
> this case will be happen very seldom. But this seems to be 
> not possible with Xen. It allows only to distribute the 
> physical memory about the machines and ensures, that the sum 
> of the domX-memory must not be larger than the available 
> physical memory. In my case I can only create 3 doms at the 
> same time. 
> 
> Is there something I'm missing? Any solution?
> 
I think you're missing an important part of the concept here. The memory
you give to DomU has to be physical memory, because it's not managed by
Dom0. It's managed by a combination of DomU (doing for example swapping)
and the hypervisor. Dom0 is not involved in any of this. The hypervisor
has no ability to swap in/out memory, so the memory you give to a DomU
has to be PHYSICALLY present in the machine. 

The reason the hypervisor can't swap is because it never was designed to
do that. It would also require the hypervisor to have knowledge of the
hard-disk layout (or you'd have to make sure that you don't need to swap
out any of Dom0 and use Dom0 to do the actual swapping - which would
make the hypervisor relatively simpler, but still make the processing of
swapping quite hard). 

The OS knows (because this is given with the flags when the memory was
allocated) which pages are swappable and which are not. This information
is not available to HV, so you'd either have to implement it blind (as
in, the HV doesn't actually know what it's swapping in/out) or extend
the information needed to be passed from the OS to HV so that it can say
"It's (not) OK to swap this page out" when you need more memory. And
whilst the first approach is POSSIBLE, it would not be very good if the
HV suddenly replaced your post for a web-forum to be transmitted by the
network card with some block of memory that came out of your
"accounts.txt" that you were editing in Xemacs and contains your account
and password info for your electronic banking web-site... ;-)

As Taneli said: why don't you swap in each DomU?

--
Mats
> Mathias
> 
> _______________________________________________
> Xen-users mailing list
> Xen-users@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-users
> 
> 


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.