From mboxrd@z Thu Jan 1 00:00:00 1970 From: Yoshiaki Tamura Subject: Re: [RFC][PATCH 12/13] Kemari: use signal to save qemu state for Kemari Date: Wed, 18 Mar 2009 21:45:31 +0900 Message-ID: <49C0ECEB.9070605@lab.ntt.co.jp> References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser Cc: "ospk-vm@lab.ntt.co.jp" , Ian Pratt , xen-devel , Ian Jackson , Stefano Stabellini List-Id: xen-devel@lists.xenproject.org Keir Fraser wrote: > On 18/03/2009 09:11, "Yoshiaki Tamura" > wrote: > >> Thanks for measuring the numbers. It made things clear. >> I think we need a signal-based interface as Ian said previously. >> >> On our test environment, AMD Barcelona 2.3GHz, the total cpu cycles of Kemari >> in >> userland when running I/O intensive applications is around 3000000. >> Although Xen transferring code and QEMU saving code is processed concurrently, >> using xenstored for staring QEMU portion would lower the performance. >> Especially if the xenstored gets slower when items are loaded. > > Using signals won't work with qemu-dm in a stub domain. Yes. I have the following options in my mind to solve it. 1. Switch using signals for qemu-dm in Dom0, and xenstored for stub domains. 2. Prepare a dedicated event channel for saving QEMU state. I guess using a dedicated event channel would be quicker than xenstored but slower than signals. If it is, using a dedicated event channel for option 1 may be better. Yoshi