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-users

Re: [Xen-users] Limits on memory which can be set using xm mem-set

To: xen-users@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-users] Limits on memory which can be set using xm mem-set
From: Mark Williamson <mark.williamson@xxxxxxxxxxxx>
Date: Sun, 16 Mar 2008 21:36:27 +0000
Cc: Jiri Denemark <jirka@xxxxxxxxxxx>
Delivery-date: Sun, 16 Mar 2008 14:37:03 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20080312194017.GD8386@xxxxxxxx>
List-help: <mailto:xen-users-request@lists.xensource.com?subject=help>
List-id: Xen user discussion <xen-users.lists.xensource.com>
List-post: <mailto:xen-users@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=unsubscribe>
References: <20080312194017.GD8386@xxxxxxxx>
Sender: xen-users-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: KMail/1.9.6 (enterprise 0.20070907.709405)
> I have a machine with Xen 3.1.3 and 4 GB of memory, 192 MB used by dom0.
> After starting a new domain with 3400 MB of memory, everything looks as
> expected.

OK.

> However, if I mem-set the memory of domU to be 160 MB, xm info 
> show more than 200 MB of "dark memory". That is, the difference between
> free memory and memory occupied by dom0+domU is greater than 200 MB. Now,
> when I connect to the domU using xm console, I can see a weird message:
>
>     Setting mem allocation to 412160 kiB
>
> /proc/meminfo in domU is consistent with it and shows MemTotal: 412160 kB

Weird!

> However, in dom0, xm list still shows the domU is provided with 160 MB of
> memory.

Really weird...!

If you try "xm info", that'll report how much free memory is *really* 
available for running domains.  This comes straight from Xen so it should be 
trustworthy.  Does it agree with what xm list is telling you?  I'm betting 
that it won't and that it'll confirm that the domain is actually 400MB, just 
as it claims.

Xen doesn't overcommit memory, so there's no way for a domain to appear to 
have more physical RAM than it's using in the host system (unless the guest 
is buggy of course ;-).

What I suspect has happened is that somehow the ballooning didn't do what you 
asked it to, but Xend just assumed that it succeeded and therefore updated 
the memory total it's reporting for that domain.

> So, Is there any limit on minimum amount of memory which can be 
> assigned to a domain using xm mem-set? Perhaps the limit is somehow related
> to the memory assigned to a domain at the time of its creation... Is this
> behaviour normal and deterministic or even described somewhere?

I think possibly there used to be a very low limit (in the 16-32MB region) for 
a minimum ballooning size for a domain.  The idea was to stop a domain being 
shrunk so much that it crashed due to memory crunch.  Maybe there's now some 
more sophisticated logic of this kind - that could be what's causing your 
problem.

If, after doing the steps you described, you reissue xm mem-set commands to 
shrink the domain to 160MB again does anything happen?  What if it's < 160MB?  
What if 160MB < xm mem-set < 400MB?  What if xm mem-set > 400? 

I've not heard of this behaviour in ballooning before, although to be honest 
I'd expect such an aggressive shrinking might upset the guest anyhow, so it's 
not necessarily something you'd want to do in production!  Still, maybe if I 
have a look through the code later I'll be able to spot a new check that's 
tripping things up.  It really ought to warn you a bit more...

Anything interesting in /var/log/xen/xend.log or /var/log/xen/xen-debug.log?

Side note: you can do something like:

echo size_in_bytes > /proc/xen/balloon

within the guest to really make it resize and bypass all checks in Xend.  This 
still won't register a change in size under xm list though, because it won't 
tell Xend about it.  Not ideal :-(

> And one more, loosely related question: can mem-set be made synchronous so
> that after xm mem-set ends ballooning is finished and memory occupied by
> the domain can be assigned to another one? That is, something similar to -w
> option of xm shutdown which blocks until the domain is down.

I don't think there's a way to do this currently.  It's perfectly possible 
technically, though.

Cheers,
Mark


-- 
Push Me Pull You - Distributed SCM tool (http://www.cl.cam.ac.uk/~maw48/pmpu/)

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

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