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 0/3] continuable destroy domain:MakeXEN_DOMCTL_de

To: <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-devel] [PATCH 0/3] continuable destroy domain:MakeXEN_DOMCTL_destroydomain hypercall continuable
From: "Szymanski, Lukasz K" <Lukasz.Szymanski@xxxxxxxxxx>
Date: Tue, 9 Oct 2007 10:49:26 -0500
Delivery-date: Tue, 09 Oct 2007 08:50:12 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <CE091CB077F4A74A9CBA33A4E4A8A3BF0B225DEC@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
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/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acfr2CdZWyirzqyJRAeWmr/EqZ6+lgABbg4wAABwhLAB/LVLkABPPLliBV7IqfAAAA+M8A==
Thread-topic: [Xen-devel] [PATCH 0/3] continuable destroy domain:MakeXEN_DOMCTL_destroydomain hypercall continuable
Keir -
 
I have put printk's with timestamps at the beginning of domain_kill() and right before the 'return -EAGAIN' call, to make sure that preemption is actually taking place.  I can see, by viewing xm dmesg, that this code gets used often during the shutdown, more and more as the memory of the vm is increased.  This is true on small commodity systems as well as the ES7000. 
 
However, I have noticed something else.  The original unresponsiveness was observed by having a shutdown in one terminal window, and xm top with a delay of 1 second in another.  As soon as xm top stopped updating the clock, the overall system responsiveness stopped with it.
 
If I do not use xm top while the vm is shutting down, there are fewer or no problem with system responsiveness. 
- If I run xm list (or xm info or xm dmesg) during a shutdown, then nothing gets listed, but I have control over all the terminals and I can ctrl-C my way out of the xm command. 
- If I do a shutdown and a non xm command such as ping, I can ping another domain and I have no responsive problems at all with zero packets lost.
 
It appears that the error is in the combination of xm commands and shutdown.  Running xm top with shutdown shows this behavior the most.
 
At this point I am trying to find out exactly when things get stuck for xm top and shutdown.
 
Luke Szymanski
Unisys Corp.
 

From: Keir Fraser [mailto:Keir.Fraser@xxxxxxxxxxxx]
Sent: Wednesday, September 12, 2007 3:35 AM
To: Krysan, Susan; yamahata@xxxxxxxxxxxxx; xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-devel] [PATCH 0/3] continuable destroy domain:MakeXEN_DOMCTL_destroydomain hypercall continuable

 

That’s quite surprising. You should add tracing to domain_kill() and find out how many times it gets preempted, how long it runs for between preemptions, etc. and hence find out whether the preemption logic is working at all for you.

 -- Keir


On 11/9/07 22:57, "Krysan, Susan" <KRYSANS@xxxxxxxxxx> wrote:

I tested the patches on Unisys ES7000 x86_64 host using 64-bit SLES10 paravirtualized domains. I compared unstable c/s 15730 and 15826 and unfortunately, the amount of time the host is unresponsive when shutting down large vms has not changed. For example, on a 32x 128gb host, the shutdown of a 62gb vm causes 1 minute and 40 seconds of host unresponsiveness both before and after the patches are applied. Also, I noticed that not only does the amount of unresponsive host time increase when the memory size of the domains increase, but it also increases when the size of the host memory increases.  Here are my test results:

 

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
<Prev in Thread] Current Thread [Next in Thread>