From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH] KVM: Avoid wasting pages for small lpage_info arrays Date: Tue, 15 May 2012 11:02:17 +0300 Message-ID: <4FB20D89.6060700@redhat.com> References: <20120510233328.d4a2623d3f8936c1b44b1f77@gmail.com> <4FAF8AFE.4020007@redhat.com> <20120514222933.94bf2c01626e28d132cf560f@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: mtosatti@redhat.com, kvm@vger.kernel.org, yoshikawa.takuya@oss.ntt.co.jp, Andrew Morton To: Takuya Yoshikawa Return-path: Received: from mx1.redhat.com ([209.132.183.28]:20300 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757766Ab2EOIC0 (ORCPT ); Tue, 15 May 2012 04:02:26 -0400 In-Reply-To: <20120514222933.94bf2c01626e28d132cf560f@gmail.com> Sender: kvm-owner@vger.kernel.org List-ID: On 05/14/2012 04:29 PM, Takuya Yoshikawa wrote: > On Sun, 13 May 2012 13:20:46 +0300 > Avi Kivity wrote: > > > I don't feel that the savings is worth the extra complication. We save > > two pages per memslot here. > > Using a 4KB vmalloced page for a 16B array is ... > > Actually I felt like you before and did not do this, but recently there > was a talk about creating hundreds of memslots. > > > What about using kvmalloc() instead of vmalloc()? It's in > > security/apparmor now, but can be made generic. > > Andrew once, maybe some times, rejected making such an API generic saying > that there should not be a generic criterion by which we can decide which > function - vmalloc() or kmalloc() - to use. > > So each caller should decide by its own criteria. > > In this case, we need to implement kvm specific kvmalloc(). > BTW, we are already doing this for dirty_bitmap. Okay, a local kvmalloc() is better than open-coding the logic. Andrew, prepare yourself for some code duplication. -- error compiling committee.c: too many arguments to function