Hi,
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
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home