From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [RFC] KVM Fault Tolerance: Kemari for KVM Date: Wed, 18 Nov 2009 15:58:32 +0200 Message-ID: <4B03FD88.5090809@redhat.com> References: <4AF79242.20406@oss.ntt.co.jp> <4AFFD96D.5090100@redhat.com> <4B015F42.7070609@oss.ntt.co.jp> <4B01667F.3000600@redhat.com> <4B028334.1070004@lab.ntt.co.jp> <87e9effc0911180528s5546c8bt383a6674b382890d@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: =?UTF-8?B?RmVybmFuZG8gTHVpcyBWw6F6cXVleiBDYW8=?= , kvm@vger.kernel.org, qemu-devel@nongnu.org, =?UTF-8?B?IuWkp+adkeWcrShvb211cmEga2VpKSI=?= , Takuya Yoshikawa , anthony@codemonkey.ws, Andrea Arcangeli , Chris Wright To: Yoshiaki Tamura Return-path: Received: from mx1.redhat.com ([209.132.183.28]:2826 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757110AbZKRN6g (ORCPT ); Wed, 18 Nov 2009 08:58:36 -0500 In-Reply-To: <87e9effc0911180528s5546c8bt383a6674b382890d@mail.gmail.com> Sender: kvm-owner@vger.kernel.org List-ID: On 11/18/2009 03:28 PM, Yoshiaki Tamura wrote: > >> I don't think lmbench is intensive but it's sensitive to memory latency. >> We'll measure kernel build time with minimum config, and post it later. >> > Here are some quick numbers of parallel kernel compile time. > The number of vcpu is 1, just for convenience. > > time make -j 2 all > ----------------------------------------------------------------------------- > Base: real 1m13.950s (user 1m2.742s, sys 0m10.446s) > Kemari: real 1m22.720s (user 1m5.882s, sys 0m10.882s) > > time make -j 4 all > ----------------------------------------------------------------------------- > Base: real 1m11.234s (user 1m2.582s, sys 0m8.643s) > Kemari: real 1m26.964s (user 1m6.530s, sys 0m12.194s) > > The result of Kemari includes everything, meaning dirty pages tracking and > synchronization upon I/O operations to the disk. > The compile time using j=4 under Kemari was worse than that of j=2, > but I'm not sure this is due to dirty pages tracking or sync interval. > Do disk writes trigger synchronization? Otherwise this is a very relaxed test. I'm surprised the degradation is so low running continuously in log-dirty. Is this an npt or ept system? Without npt or ept I'd expect less degradation since the page tables are heavily manipulated anyway. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NAl3W-0003YJ-TO for qemu-devel@nongnu.org; Wed, 18 Nov 2009 08:58:47 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NAl3S-0003WH-Rb for qemu-devel@nongnu.org; Wed, 18 Nov 2009 08:58:46 -0500 Received: from [199.232.76.173] (port=44853 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NAl3S-0003W7-2k for qemu-devel@nongnu.org; Wed, 18 Nov 2009 08:58:42 -0500 Received: from mx1.redhat.com ([209.132.183.28]:8608) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NAl3R-0005Qz-H0 for qemu-devel@nongnu.org; Wed, 18 Nov 2009 08:58:41 -0500 Message-ID: <4B03FD88.5090809@redhat.com> Date: Wed, 18 Nov 2009 15:58:32 +0200 From: Avi Kivity MIME-Version: 1.0 References: <4AF79242.20406@oss.ntt.co.jp> <4AFFD96D.5090100@redhat.com> <4B015F42.7070609@oss.ntt.co.jp> <4B01667F.3000600@redhat.com> <4B028334.1070004@lab.ntt.co.jp> <87e9effc0911180528s5546c8bt383a6674b382890d@mail.gmail.com> In-Reply-To: <87e9effc0911180528s5546c8bt383a6674b382890d@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [RFC] KVM Fault Tolerance: Kemari for KVM List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Yoshiaki Tamura Cc: Andrea Arcangeli , Chris Wright , =?UTF-8?B?IuWkp+adkeWcrShvb211cmEga2VpKSI=?= , kvm@vger.kernel.org, =?UTF-8?B?RmVybmFuZG8gTHVpcyBWw6F6cXVleiBDYW8=?= , qemu-devel@nongnu.org, Takuya Yoshikawa On 11/18/2009 03:28 PM, Yoshiaki Tamura wrote: > >> I don't think lmbench is intensive but it's sensitive to memory latency. >> We'll measure kernel build time with minimum config, and post it later. >> > Here are some quick numbers of parallel kernel compile time. > The number of vcpu is 1, just for convenience. > > time make -j 2 all > ----------------------------------------------------------------------------- > Base: real 1m13.950s (user 1m2.742s, sys 0m10.446s) > Kemari: real 1m22.720s (user 1m5.882s, sys 0m10.882s) > > time make -j 4 all > ----------------------------------------------------------------------------- > Base: real 1m11.234s (user 1m2.582s, sys 0m8.643s) > Kemari: real 1m26.964s (user 1m6.530s, sys 0m12.194s) > > The result of Kemari includes everything, meaning dirty pages tracking and > synchronization upon I/O operations to the disk. > The compile time using j=4 under Kemari was worse than that of j=2, > but I'm not sure this is due to dirty pages tracking or sync interval. > Do disk writes trigger synchronization? Otherwise this is a very relaxed test. I'm surprised the degradation is so low running continuously in log-dirty. Is this an npt or ept system? Without npt or ept I'd expect less degradation since the page tables are heavily manipulated anyway. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.