From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [PATCH] QEMU/KVM: large page support Date: Sat, 23 Feb 2008 16:56:12 -0600 Message-ID: <47C0A48C.20802@codemonkey.ws> References: <20080223144812.GB1040@dmt> <47C06607.80200@codemonkey.ws> <20080223225407.GA8465@dmt> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-devel , Avi Kivity To: Marcelo Tosatti Return-path: In-Reply-To: <20080223225407.GA8465@dmt> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces@lists.sourceforge.net Errors-To: kvm-devel-bounces@lists.sourceforge.net List-Id: kvm.vger.kernel.org Marcelo Tosatti wrote: > I thought about doing that (gets rid of the 4GB+ special casing) but we > lose the ability to compact smaller allocations in a single largepage. > > Right now the VGA BIOS and the BIOS fit in the same largepage, for > example. > Ah, good point. I was actually talking about doing this adjustment for ram regardless of whether we're using large pages--not necessarily for all memory allocations. I saw no harm in doing this alignment even if we were using tmpfs and just getting 4k pages. Of course, I think we're in agreement here though :-) > I like the idea. I'll change "-hugetlb-path" to "-mem-path" for now (and > test it with tmpfs). Not so fond of hardcoding a path in QEMU though. > If we had a unified tmpfs/hugetlbfs, I think it would make a lot of sense. I think I need to ask around though first and see how reasonable that is. Regards, Anthony Liguori ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/