From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NrvmP-0000IJ-68 for qemu-devel@nongnu.org; Wed, 17 Mar 2010 12:07:33 -0400 Received: from [199.232.76.173] (port=53340 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NrvmN-0000Ga-G1 for qemu-devel@nongnu.org; Wed, 17 Mar 2010 12:07:31 -0400 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1NrvmM-0001rB-Ms for qemu-devel@nongnu.org; Wed, 17 Mar 2010 12:07:31 -0400 Received: from mx20.gnu.org ([199.232.41.8]:5488) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NrvmM-0001r7-Gk for qemu-devel@nongnu.org; Wed, 17 Mar 2010 12:07:30 -0400 Received: from mail.codesourcery.com ([38.113.113.100]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NrvmL-00056Y-PQ for qemu-devel@nongnu.org; Wed, 17 Mar 2010 12:07:30 -0400 From: Paul Brook Subject: Re: [Qemu-devel] [PATCH QEMU] Transparent Hugepage Support #3 Date: Wed, 17 Mar 2010 16:07:09 +0000 References: <20100317145950.GA5752@random.random> <201003171552.15230.paul@codesourcery.com> <20100317155542.GE5752@random.random> In-Reply-To: <20100317155542.GE5752@random.random> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201003171607.09326.paul@codesourcery.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Andrea Arcangeli Cc: qemu-devel@nongnu.org, Avi Kivity > On Wed, Mar 17, 2010 at 03:52:15PM +0000, Paul Brook wrote: > > > > > Size not multiple I think is legitimate, the below-4G chunk isn't > > > > > required to end 2M aligned, all it matters is that the above-4G > > > > > then starts aligned. In short one thing to add in the future as > > > > > parameter to qemu_ram_alloc is the physical address that the host > > > > > virtual address corresponds to. > > > > > > > > In general you don't know this at allocation time. > > > > > > Caller knows it, it's not like the caller is outside of qemu, it's not > > > some library. We know this is enough with the caller that there is now. > > > > No we don't. As discussed previously, there are machines where the > > physical location of RAM is configurable at runtime. In fact it's common > > for the ram to be completely absent at reset. > > This is why PREFERRED_RAM_ALIGN is only defined for __x86_64__. I'm > not talking about other archs that may never support transparent > hugepages in the kernel because of other architectural constrains that > may prevent to map hugepages mixed with regular pages in the same vma. __x86__64 only tells you about the host. I'm talking about the guest machine. Paul