From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matt Evans Subject: Re: [PATCH V2 17/23] kvm tools: Add ability to map guest RAM from hugetlbfs Date: Mon, 12 Dec 2011 16:17:29 +1100 Message-ID: <4EE58E69.40006@ozlabs.org> References: <4EE1B0DD.6030004@ozlabs.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org, kvm-ppc@vger.kernel.org, asias.hejun@gmail.com, levinsasha928@gmail.com, gorcunov@gmail.com, Ingo Molnar To: Pekka Enberg Return-path: In-Reply-To: Sender: kvm-ppc-owner@vger.kernel.org List-Id: kvm.vger.kernel.org On 09/12/11 19:42, Pekka Enberg wrote: > On Fri, Dec 9, 2011 at 8:55 AM, Matt Evans wrote: >> Add a --hugetlbfs commandline option to give a path to hugetlbfs-map guest >> memory (down in kvm__arch_init()). For x86, guest memory is a normal >> ANON mmap() if this option is not provided, otherwise a hugetlbfs mmap. >> >> Signed-off-by: Matt Evans > > Btw, why don't you want to use MADV_HUGEPAGE for this? You could just > do it unconditionally, no? Well, I'm manually mapping from hugetlbfs as currently* PPC KVM requires hugepages to back guest RAM and MADV_HUGEPAGE is just a hint, no? I also wanted things to work on kernels without transparent hugepages enabled. I think it's safer to do things explicitly, as if the user requests hugepages it's more transparent (I'm thinking benchmarking, etc.) to be definitely using hugepages. Cheers, Matt *: I know Paul's posted patches to implement smallpage support... so this will change in time.