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] about hot plug issue

To: "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-devel] about hot plug issue
From: "Yu, Ping Y" <ping.y.yu@xxxxxxxxx>
Date: Tue, 26 Sep 2006 18:20:59 +0800
Cc: sos22@xxxxxxxxx, Steven Hand <steven.hand@xxxxxxxxxxxx>, Christian.Limpach@xxxxxxxxxxxxx
Delivery-date: Tue, 26 Sep 2006 03:22:47 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
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: AcbhPoDCejFEsZRAQd24zSmg/cIN+wAALgcsAAF9vhAAAcUFpgACMmlQ
Thread-topic: [Xen-devel] about hot plug issue
>Or we could work out how we are chewing up dom0 for 10s per created
domain.
>Is the total time to create 12 domains less if you create them one
after
>another (serially) rather than issuing the xm requests all at the same
time?
>I wonder if creating many domains in parallel is thrashing domain 0
somehow.

We have tried to start 14 domains in serial, and the total time is 2
minutes 
21 seconds, and if staring in parallel, the total time is 1 minutes 51
second,
counting from "xm create" to message "Started domain domain_name)
Hope this info is useful to you. :-)
>
>>>> At the same time, we found when main_loop_wait is increased to
>>>> 100 ms, windows guest's keyboard and mouse response is
>>>> significantly slower.
>>>
>>> Perhaps we need a single polling daemon that can demux kb/mouse
events
>> to
>>> all qemu instances in a way that can be select()ed on. That would
avoid
>>> unscalable polling overheads.
>> Good solution. Could you make a patch for this? :-)
>
>I need to discuss with other Cambridge folks. Moving to qemu stub
domain and
>split driver for kb/mouse input will solve this issue anyway in the
longer
>term.
>
> -- Keir

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