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/
Home Products Support Community News


[Xen-devel] Re: [RFC][Patch] Improvemet the responce of xend.

To: <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] Re: [RFC][Patch] Improvemet the responce of xend.
From: Peter Teoh <htmldeveloper@xxxxxxxxx>
Date: Fri, 31 Aug 2007 14:37:24 +0800
Delivery-date: Thu, 13 Sep 2007 05:26:38 -0700
Dkim-signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:to:subject:date:mime-version:content-type:x-priority:x-msmail-priority:x-mailer:x-mimeole:from; b=L3b9JY91sgd9Qmrbrq/gCWLcrN4ochzcxiy8bj2OhhtM5H3eOPkdG2QOdC0bJ+tMe5Wq8KoxnWQEVsOTygHBzlHNLvGufoIxY1aaLKfQ+j0mLdUEDgkOwkGrXJT/8HEhGCCDGOAmZDAABqoHvrbGXqOF3bmvy86sOhJkMaha8Do=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:to:subject:date:mime-version:content-type:x-priority:x-msmail-priority:x-mailer:x-mimeole:from; b=NtVw5lq83+0eSgHL8fWEzd7TJDoEKEIZ1FgGoqsmGtQIG2cjNrsmithNwGkdu37MNqLn4jGW9+Dh9sXAtSQ363VKS3YX5u2smos8ILLHMp3fPEvIlLOmCkKp+1FwNttrJi3a0oadrzJowfw65q4+b8+o1DHRxieTPKlNKl+A8aE=
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
A few comments:
a.   The patch basically spawn a new process to handle the additional "xm" inputs asynchronously.   Correct?   And since currently this is not possible, it also means that the possibilities of deadlocks or race conditions through concurrent access to xend via different xm users is not thoroughly verified.   Correct?   May be.   So this is something to look out for.
b.   The performance of dump core is slow, mainly because external hard disk are slow.   Therefore, there could be four different options/variations:   minidump vs full-dump.   For each there could be a compressed vs no-compression option - compressed is to get a smaller physical core.  
c.   Furthermore, there could be an additional throttling parameters to specify how much to slow the coredump operation, for example, by forcing a CPU re-scheduling operation (higher overheads in task switching - tradeoff for responsiveness) after every fix number of blocks.   This will also have the effect of improving performance for additional domU's operation.
Thank you very much.
Xen-devel mailing list
<Prev in Thread] Current Thread [Next in Thread>