Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755275Ab2F1PNZ (ORCPT ); Thu, 28 Jun 2012 11:13:25 -0400 Received: from g5t0008.atlanta.hp.com ([15.192.0.45]:10270 "EHLO g5t0008.atlanta.hp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751459Ab2F1PNX (ORCPT ); Thu, 28 Jun 2012 11:13:23 -0400 Message-ID: <4FEC7487.9020909@hp.com> Date: Thu, 28 Jun 2012 08:13:11 -0700 From: Don Morris User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Andrea Arcangeli CC: linux-kernel@vger.kernel.org, linux-mm@kvack.org, Hillf Danton , Dan Smith , Peter Zijlstra , Linus Torvalds , Andrew Morton , Thomas Gleixner , Ingo Molnar , Paul Turner , Suresh Siddha , Mike Galbraith , "Paul E. McKenney" , Lai Jiangshan , Bharata B Rao , Lee Schermerhorn , Rik van Riel , Johannes Weiner , Srivatsa Vaddagiri , Christoph Lameter , Alex Shi , Mauricio Faria de Oliveira , Konrad Rzeszutek Wilk , Benjamin Herrenschmidt Subject: Re: [PATCH 05/40] autonuma: define _PAGE_NUMA_PTE and _PAGE_NUMA_PMD References: <1340888180-15355-1-git-send-email-aarcange@redhat.com> <1340888180-15355-6-git-send-email-aarcange@redhat.com> In-Reply-To: <1340888180-15355-6-git-send-email-aarcange@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2868 Lines: 77 On 06/28/2012 05:55 AM, Andrea Arcangeli wrote: > We will set these bitflags only when the pmd and pte is non present. > Just a couple grammar nitpicks. > They work like PROT_NONE but they identify a request for the numa > hinting page fault to trigger. > > Because we want to be able to set these bitflag in any established pte these bitflags > or pmd (while clearing the present bit at the same time) without > losing information, these bitflags must never be set when the pte and > pmd are present. > > For _PAGE_NUMA_PTE the pte bitflag used is _PAGE_PSE, which cannot be > set on ptes and it also fits in between _PAGE_FILE and _PAGE_PROTNONE > which avoids having to alter the swp entries format. > > For _PAGE_NUMA_PMD, we use a reserved bitflag. pmds never contain > swap_entries but if in the future we'll swap transparent hugepages, we > must keep in mind not to use the _PAGE_UNUSED2 bitflag in the swap > entry format and to start the swap entry offset above it. > > PAGE_UNUSED2 is used by Xen but only on ptes established by ioremap, > but it's never used on pmds so there's no risk of collision with Xen. Maybe "but only on ptes established by ioremap, never on pmds so there's no risk of collision with Xen." ? The extra "but" just doesn't flow in the original. Don Morris > > Signed-off-by: Andrea Arcangeli > --- > arch/x86/include/asm/pgtable_types.h | 11 +++++++++++ > 1 files changed, 11 insertions(+), 0 deletions(-) > > diff --git a/arch/x86/include/asm/pgtable_types.h b/arch/x86/include/asm/pgtable_types.h > index b74cac9..6e2d954 100644 > --- a/arch/x86/include/asm/pgtable_types.h > +++ b/arch/x86/include/asm/pgtable_types.h > @@ -71,6 +71,17 @@ > #define _PAGE_FILE (_AT(pteval_t, 1) << _PAGE_BIT_FILE) > #define _PAGE_PROTNONE (_AT(pteval_t, 1) << _PAGE_BIT_PROTNONE) > > +/* > + * Cannot be set on pte. The fact it's in between _PAGE_FILE and > + * _PAGE_PROTNONE avoids having to alter the swp entries. > + */ > +#define _PAGE_NUMA_PTE _PAGE_PSE > +/* > + * Cannot be set on pmd, if transparent hugepages will be swapped out > + * the swap entry offset must start above it. > + */ > +#define _PAGE_NUMA_PMD _PAGE_UNUSED2 > + > #define _PAGE_TABLE (_PAGE_PRESENT | _PAGE_RW | _PAGE_USER | \ > _PAGE_ACCESSED | _PAGE_DIRTY) > #define _KERNPG_TABLE (_PAGE_PRESENT | _PAGE_RW | _PAGE_ACCESSED | \ > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majordomo@kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: email@kvack.org > . > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/