From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Nq7LY-0004N0-4Z for qemu-devel@nongnu.org; Fri, 12 Mar 2010 11:04:20 -0500 Received: from [199.232.76.173] (port=50553 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nq7LX-0004MN-Ni for qemu-devel@nongnu.org; Fri, 12 Mar 2010 11:04:19 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1Nq7LX-0000jL-06 for qemu-devel@nongnu.org; Fri, 12 Mar 2010 11:04:19 -0500 Received: from mx20.gnu.org ([199.232.41.8]:54710) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Nq7LW-0000jF-R4 for qemu-devel@nongnu.org; Fri, 12 Mar 2010 11:04:18 -0500 Received: from mail.codesourcery.com ([38.113.113.100]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Nq7LW-000107-2R for qemu-devel@nongnu.org; Fri, 12 Mar 2010 11:04:18 -0500 From: Paul Brook Subject: Re: [Qemu-devel] [PATCH QEMU] transparent hugepage support Date: Fri, 12 Mar 2010 16:04:03 +0000 References: <20100311151427.GE5677@random.random> <201003121136.33916.paul@codesourcery.com> <20100312145228.GR5677@random.random> In-Reply-To: <20100312145228.GR5677@random.random> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201003121604.04913.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 > > > $ cat /sys/kernel/mm/transparent_hugepage/hpage_pmd_size > > > 2097152 > > > > Is "pmd" x86 specific? > > It's linux specific, this is common code, nothing x86 specific. In > fact on x86 it's not called pmd but Page Directory. I've actually no > idea what pmd stands for but it's definitely not x86 specific and it's > just about the linux common code common to all archs. The reason this > is called hpage_pmd_size is because it's a #define HPAGE_PMD_SIZE in > the kernel code. So this entirely match the kernel internals > _common_code_. 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". Paul