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: Wed, 16 May 2012 12:26:40 +0300 Message-ID: <4FB372D0.9030801@redhat.com> References: <20120510233328.d4a2623d3f8936c1b44b1f77@gmail.com> <4FAF8AFE.4020007@redhat.com> <20120514222933.94bf2c01626e28d132cf560f@gmail.com> <4FB20D89.6060700@redhat.com> <20120515132551.b204110e.akpm@linux-foundation.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Takuya Yoshikawa , mtosatti@redhat.com, kvm@vger.kernel.org, yoshikawa.takuya@oss.ntt.co.jp To: Andrew Morton Return-path: Received: from mx1.redhat.com ([209.132.183.28]:15909 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752879Ab2EPJ0r (ORCPT ); Wed, 16 May 2012 05:26:47 -0400 In-Reply-To: <20120515132551.b204110e.akpm@linux-foundation.org> Sender: kvm-owner@vger.kernel.org List-ID: On 05/15/2012 11:25 PM, Andrew Morton wrote: > On Tue, 15 May 2012 11:02:17 +0300 > Avi Kivity wrote: > > > 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. > > There are reasons for avoiding vmalloc(). > > The kernel does not run in a virtual memory environment. It is a > harsh, low-level environment and kernel code should be robust. This is about downgrading an existing vmalloc() to kmalloc(), when the sizes permit, to reduce wastage. Not about upgrading a kmalloc() to vmalloc(). > Assuming that you can allocate vast amounts of contiguous memory is not > robust. Robust code will implement data structures which avoid this > weakness. This is true on some architectures. On others vast amounts of contiguous memory _are_ available, and implementing software radix trees to replace the hardware radix trees is not going to improve things. -- error compiling committee.c: too many arguments to function