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: Thu, 19 Mar 2009 15:07:32 +0900 Message-ID: <49C1E124.4000108@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> <49C0BAC6.7070103@lab.ntt.co.jp> <49C13160.5040502@cs.ubc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <49C13160.5040502@cs.ubc.ca> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Christopher Head Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org Christopher Head wrote: > -----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. Thanks for your info:) It's good to know that we weren't the only who wanted this kind of interface. Yoshi