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 18:11:34 +0900 Message-ID: <49C0BAC6.7070103@lab.ntt.co.jp> References: <49B0B8DC.5000606@lab.ntt.co.jp> <49B0C6FF.8090903@lab.ntt.co.jp> <49B10B8D.6090505@eu.citrix.com> <49B14D4B.7090300@lab.ntt.co.jp> <49BFE419.5080103@eu.citrix.com> <18879.59975.103026.803462@mariner.uk.xensource.com> <49BFED6A.3050805@eu.citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <49BFED6A.3050805@eu.citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Stefano Stabellini Cc: "ospk-vm@lab.ntt.co.jp" , Ian Pratt , xen-devel , Ian Jackson , Keir Fraser List-Id: xen-devel@lists.xenproject.org Stefano Stabellini wrote: > Ian Jackson wrote: > >> Stefano Stabellini writes ("Re: [Xen-devel] [RFC][PATCH 12/13] Kemari: use signal to save qemu state for Kemari"): >>> I did a couple of quick tests and it seems that signals are faster then >>> xenstore but still xenstore offers good performances. >>> >>> I measured the time using rdtsc at the sender size and at the receiver >>> size, the difference between the two values is the following: >>> >>> signals: 368836 >>> xenstore: 1984632 >> This is with an unloaded xenstored, I take it. > > > Yes 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. Yoshi