From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: patch: qemu + hugetlbfs.. Date: Thu, 10 Jul 2008 16:38:38 -0500 Message-ID: <4876815E.3010109@codemonkey.ws> References: <4873E400.4000409@third-harmonic.com> <4873F395.6030209@codemonkey.ws> <4874051A.8000802@third-harmonic.com> <48740F86.3050306@codemonkey.ws> <20080709170301.GA11439@dmt.cnet> <4874F156.2010708@codemonkey.ws> <48763B86.6060402@third-harmonic.com> <48764DAF.6060502@codemonkey.ws> <48766E03.4090901@third-harmonic.com> <48767558.50301@codemonkey.ws> <48767B20.20806@third-harmonic.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Marcelo Tosatti , kvm@vger.kernel.org, john.cooper@redhat.com To: john cooper Return-path: Received: from yw-out-2324.google.com ([74.125.46.28]:62191 "EHLO yw-out-2324.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752991AbYGJVju (ORCPT ); Thu, 10 Jul 2008 17:39:50 -0400 Received: by yw-out-2324.google.com with SMTP id 9so1732767ywe.1 for ; Thu, 10 Jul 2008 14:39:34 -0700 (PDT) In-Reply-To: <48767B20.20806@third-harmonic.com> Sender: kvm-owner@vger.kernel.org List-ID: john cooper wrote: > Anthony Liguori wrote: >> john cooper wrote: >>> As it currently exists alloc_hpage_mem() is tied to >>> the notion of huge page allocation as it will reference >>> gethugepagesize() irrespective of *mem_path. So even >>> in the case of tmpfs backed files, if the host kernel >>> has been configured with CONFIG_HUGETLBFS we will wind >>> up doing allocations of /dev/shm mapped files at >>> /proc/meminfo:Hugepagesize granularity. >> >> Which is fine. It just means we round -m values up to even numbers. > > Well, yes it will round the allocation. But from a > minimally sufficient 4KB boundary to that of 4MB/2MB > relative to a 32/64 bit x86 host which is excessive. > >>> Probably not what was intended but probably not too >>> much of a concern as "-mem-path /dev/shm" is likely >>> only used in debug of this flag and associated logic. >>> I don't see it currently being worth the trouble to >>> correct from a squeaky clean POV, and doing so may >>> drag in far more than the header file we've just >>> booted above to deal with this architecture/config >>> dependency. >> >> Renaming a function to a name that's less accurate seems bad to me. >> I don't mean to be pedantic, but it seems like a strange thing to >> do. I prefer it the way it was before. > > I don't see any harm reverting the name. But I do > believe it is largely cosmetic as given the above, > the current code does require some work to make it > independent of huge page assumptions. Update attached. > > -john Looks good to me. Acked-by: Anthony Liguori