From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 1/1] KVM: x86: avoid unnecessary bitmap allocation when memslot is clean Date: Wed, 28 Apr 2010 13:26:43 +0300 Message-ID: <4BD80D63.2090600@redhat.com> References: <20100426185657.7f68c3ad.yoshikawa.takuya@oss.ntt.co.jp> <20100426185854.5d606a04.yoshikawa.takuya@oss.ntt.co.jp> <4BD6E412.7090202@redhat.com> <4BD6EACF.6070205@oss.ntt.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mtosatti@redhat.com, kvm@vger.kernel.org To: Takuya Yoshikawa Return-path: Received: from mx1.redhat.com ([209.132.183.28]:27629 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751673Ab0D1LS3 (ORCPT ); Wed, 28 Apr 2010 07:18:29 -0400 In-Reply-To: <4BD6EACF.6070205@oss.ntt.co.jp> Sender: kvm-owner@vger.kernel.org List-ID: On 04/27/2010 04:46 PM, Takuya Yoshikawa wrote: > (2010/04/27 22:18), Avi Kivity wrote: > >>> Furthermore, the reduced allocations seem to produce good effects for >>> other cases too. Actually, I observed that the time for the ioctl was >>> more stable than the original one and the average time for dirty slots >>> was also reduced by some extent. >> >> Can you explain why the dirty slots were improved? > > I cannot do exactly, but vmalloc() might affect the following > allocations? > > But actually, I could check how much one vmalloc() consumed our time, > and this will be completely removed by our "moving dirty bitmaps to > user space". > > > Better to remove this explanation about dirty slots? I guess so. > > BTW, maybe good news for us! > > 1. I found one place in which set_bit_to_user() is locally defined using > current helpers. Interesting, where? -- error compiling committee.c: too many arguments to function