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


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

To: Peter Teoh <htmldeveloper@xxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-devel] Re: [RFC][Patch] Improvemet the responce of xend.
From: Akio Takebe <takebe_akio@xxxxxxxxxxxxxx>
Date: Thu, 13 Sep 2007 22:44:43 +0900
Delivery-date: Thu, 13 Sep 2007 06:45:33 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <05f801c7eb99$7639c690$9a010a0a@eeyore>
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>
References: <05f801c7eb99$7639c690$9a010a0a@eeyore>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx

Thank you for your comments.

>A few comments:
>a.   The patch basically spawn a new process to handle the additional "xm" 
>inputs asynchronously.   Correct? 
Yes, but currently only at the time of dump-core.

>  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.
I don't understand completely what you said.
Basicaly xend work one by one,
so if xm requests dump-core, xend work only for it.
I think it is difficult to change xend to multi thread.
But because dump-core work is very simple,
Xend should be able to let another process do dump-core work.

When I posted my patch, I had a mistake that I don't open socket for xenstore.
Now we're making another patch with other approach.
If xend get a dump-core request, xend does fork() and exec(xc_dump)
(like xc_save, xc_restore). 
If the child process wants to write something into xensotre,
it can do by using xs_daemon_open(), xs_write() and so on. (I think)

We concern with what we should do if another xm request destory
to the dumped domain.

>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.   
Yes, I also think so and want their options.
But I don't think the performance yet.

>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.
We may be able to do it by nice command
if xend let another process do dump-core work.

Best Regards,

Akio Takebe

Xen-devel mailing list

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