From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christopher Head Subject: Re: [RFC][PATCH 12/13] Kemari: use signal to save qemu state for Kemari Date: Wed, 18 Mar 2009 10:37:36 -0700 Message-ID: <49C13160.5040502@cs.ubc.ca> 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> <49C0BAC6.7070103@lab.ntt.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <49C0BAC6.7070103@lab.ntt.co.jp> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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. > > Yoshi For Remus, we ended up using a Unix-domain socket to handshake with QEMU for suspend/resume, for the same reason (to improve performance compared to Xenstore). Just another approach :) and also another approach that won't work with stubdom. Chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: GnuPT 2.7.2 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknBMV8ACgkQXUF6hOTGP7eGCQCfZrO7mauFehuKtGdyyF2hOOIw QQgAn01JCwlMf0yYRSpwgG4z+KC4qYmo =6sjl -----END PGP SIGNATURE-----