From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Nq7fD-0005VP-6u for qemu-devel@nongnu.org; Fri, 12 Mar 2010 11:24:39 -0500 Received: from [199.232.76.173] (port=45801 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nq7fC-0005Up-FT for qemu-devel@nongnu.org; Fri, 12 Mar 2010 11:24:38 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1Nq7fB-0002f3-NR for qemu-devel@nongnu.org; Fri, 12 Mar 2010 11:24:38 -0500 Received: from mx20.gnu.org ([199.232.41.8]:54913) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Nq7fB-0002ex-Gp for qemu-devel@nongnu.org; Fri, 12 Mar 2010 11:24:37 -0500 Received: from mail.codesourcery.com ([38.113.113.100]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Nq7fA-0001Ov-6C for qemu-devel@nongnu.org; Fri, 12 Mar 2010 11:24:36 -0500 From: Paul Brook Subject: Re: [Qemu-devel] [PATCH QEMU] transparent hugepage support Date: Fri, 12 Mar 2010 16:24:24 +0000 References: <20100311151427.GE5677@random.random> <201003121604.04913.paul@codesourcery.com> <20100312161724.GT5677@random.random> In-Reply-To: <20100312161724.GT5677@random.random> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201003121624.24870.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 Fri, Mar 12, 2010 at 04:04:03PM +0000, Paul Brook wrote: > > > > > $ cat /sys/kernel/mm/transparent_hugepage/hpage_pmd_size > > > > > 2097152 > > > Hmm, ok. I'm guessing linux doesn't support anything other than "huge" > > and "normal" page sizes now, so it's a question of whether we want it to > > expose current implementation details, or say "Align big in-memory things > > this much for optimal TLB behavior". > > hugetlbfs already exposes the implementation detail. So if you want > that it's already available. The whole point of going the extra mile > with a transparent solution is to avoid userland to increase in > complexity and to keep it as unaware of hugepages as possible. The > madvise hint basically means "this won't risk to waste memory if you > use large tlb on this mapping" and also "this mapping is more > important than others to be backed by hugepages". It's up to the > kernel what to do next. For example right now khugepaged doesn't > prioritize scanning the madvise regions first, it basically doesn't > matter for hypervisor solutions in the cloud (all anon memory in the > system is only allocated by kvm...). But later we may prioritize it > and try to be smarter from the hint given by userland. So shouldn't [the name of] the value the kernel provides for recommended alignment be equally implementation agnostic? Paul