From: Steve Capper <steve.capper@linaro.org> To: Will Deacon <will.deacon@arm.com> Cc: "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org>, Catalin Marinas <Catalin.Marinas@arm.com>, "linux@arm.linux.org.uk" <linux@arm.linux.org.uk>, "linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>, "linux-mm@kvack.org" <linux-mm@kvack.org>, "gary.robertson@linaro.org" <gary.robertson@linaro.org>, "christoffer.dall@linaro.org" <christoffer.dall@linaro.org>, "peterz@infradead.org" <peterz@infradead.org>, "anders.roxell@linaro.org" <anders.roxell@linaro.org>, "akpm@linux-foundation.org" <akpm@linux-foundation.org> Subject: Re: [PATCH 2/6] arm: mm: Introduce special ptes for LPAE Date: Fri, 27 Jun 2014 13:44:37 +0100 [thread overview] Message-ID: <20140627124436.GC30585@linaro.org> (raw) In-Reply-To: <20140627121721.GM26276@arm.com> On Fri, Jun 27, 2014 at 01:17:21PM +0100, Will Deacon wrote: > On Wed, Jun 25, 2014 at 04:40:20PM +0100, Steve Capper wrote: > > We need a mechanism to tag ptes as being special, this indicates that > > no attempt should be made to access the underlying struct page * > > associated with the pte. This is used by the fast_gup when operating on > > ptes as it has no means to access VMAs (that also contain this > > information) locklessly. > > > > The L_PTE_SPECIAL bit is already allocated for LPAE, this patch modifies > > pte_special and pte_mkspecial to make use of it, and defines > > __HAVE_ARCH_PTE_SPECIAL. > > > > This patch also excludes special ptes from the icache/dcache sync logic. > > > > Signed-off-by: Steve Capper <steve.capper@linaro.org> > > --- > > arch/arm/include/asm/pgtable-2level.h | 2 ++ > > arch/arm/include/asm/pgtable-3level.h | 8 ++++++++ > > arch/arm/include/asm/pgtable.h | 6 ++---- > > 3 files changed, 12 insertions(+), 4 deletions(-) > > > > diff --git a/arch/arm/include/asm/pgtable-2level.h b/arch/arm/include/asm/pgtable-2level.h > > index 219ac88..f027941 100644 > > --- a/arch/arm/include/asm/pgtable-2level.h > > +++ b/arch/arm/include/asm/pgtable-2level.h > > @@ -182,6 +182,8 @@ static inline pmd_t *pmd_offset(pud_t *pud, unsigned long addr) > > #define pmd_addr_end(addr,end) (end) > > > > #define set_pte_ext(ptep,pte,ext) cpu_set_pte_ext(ptep,pte,ext) > > +#define pte_special(pte) (0) > > +static inline pte_t pte_mkspecial(pte_t pte) { return pte; } > > > > /* > > * We don't have huge page support for short descriptors, for the moment > > diff --git a/arch/arm/include/asm/pgtable-3level.h b/arch/arm/include/asm/pgtable-3level.h > > index 85c60ad..b286ba9 100644 > > --- a/arch/arm/include/asm/pgtable-3level.h > > +++ b/arch/arm/include/asm/pgtable-3level.h > > @@ -207,6 +207,14 @@ static inline pmd_t *pmd_offset(pud_t *pud, unsigned long addr) > > #define pte_huge(pte) (pte_val(pte) && !(pte_val(pte) & PTE_TABLE_BIT)) > > #define pte_mkhuge(pte) (__pte(pte_val(pte) & ~PTE_TABLE_BIT)) > > > > +#define pte_special(pte) (!!(pte_val(pte) & L_PTE_SPECIAL)) > > Why the !!? Also, shouldn't this be rebased on your series adding the > pte_isset macro to ARM? Yes it should, I had this series logically separate to the pte_isset patch. I will have the pte_isset patch as a pre-requisite to the ARM fast_gup activation logic. > > > +static inline pte_t pte_mkspecial(pte_t pte) > > +{ > > + pte_val(pte) |= L_PTE_SPECIAL; > > + return pte; > > +} > > If you put this in pgtable.h based on #ifdef __HAVE_ARCH_PTE_SPECIAL, then > you can use PTE_BIT_FUNC to avoid reinventing the wheel (or define > L_PTE_SPECIAL as 0 for 2-level and have one function). Thanks, I'll give this a go. Cheers, -- Steve -- 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: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Steve Capper <steve.capper@linaro.org> To: Will Deacon <will.deacon@arm.com> Cc: "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org>, Catalin Marinas <Catalin.Marinas@arm.com>, "linux@arm.linux.org.uk" <linux@arm.linux.org.uk>, "linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>, "linux-mm@kvack.org" <linux-mm@kvack.org>, "gary.robertson@linaro.org" <gary.robertson@linaro.org>, "christoffer.dall@linaro.org" <christoffer.dall@linaro.org>, "peterz@infradead.org" <peterz@infradead.org>, "anders.roxell@linaro.org" <anders.roxell@linaro.org>, "akpm@linux-foundation.org" <akpm@linux-foundation.org> Subject: Re: [PATCH 2/6] arm: mm: Introduce special ptes for LPAE Date: Fri, 27 Jun 2014 13:44:37 +0100 [thread overview] Message-ID: <20140627124436.GC30585@linaro.org> (raw) Message-ID: <20140627124437.auCMvq19hqPMbxN52p6yHds2sGHenpvMfHAC9JBL-90@z> (raw) In-Reply-To: <20140627121721.GM26276@arm.com> On Fri, Jun 27, 2014 at 01:17:21PM +0100, Will Deacon wrote: > On Wed, Jun 25, 2014 at 04:40:20PM +0100, Steve Capper wrote: > > We need a mechanism to tag ptes as being special, this indicates that > > no attempt should be made to access the underlying struct page * > > associated with the pte. This is used by the fast_gup when operating on > > ptes as it has no means to access VMAs (that also contain this > > information) locklessly. > > > > The L_PTE_SPECIAL bit is already allocated for LPAE, this patch modifies > > pte_special and pte_mkspecial to make use of it, and defines > > __HAVE_ARCH_PTE_SPECIAL. > > > > This patch also excludes special ptes from the icache/dcache sync logic. > > > > Signed-off-by: Steve Capper <steve.capper@linaro.org> > > --- > > arch/arm/include/asm/pgtable-2level.h | 2 ++ > > arch/arm/include/asm/pgtable-3level.h | 8 ++++++++ > > arch/arm/include/asm/pgtable.h | 6 ++---- > > 3 files changed, 12 insertions(+), 4 deletions(-) > > > > diff --git a/arch/arm/include/asm/pgtable-2level.h b/arch/arm/include/asm/pgtable-2level.h > > index 219ac88..f027941 100644 > > --- a/arch/arm/include/asm/pgtable-2level.h > > +++ b/arch/arm/include/asm/pgtable-2level.h > > @@ -182,6 +182,8 @@ static inline pmd_t *pmd_offset(pud_t *pud, unsigned long addr) > > #define pmd_addr_end(addr,end) (end) > > > > #define set_pte_ext(ptep,pte,ext) cpu_set_pte_ext(ptep,pte,ext) > > +#define pte_special(pte) (0) > > +static inline pte_t pte_mkspecial(pte_t pte) { return pte; } > > > > /* > > * We don't have huge page support for short descriptors, for the moment > > diff --git a/arch/arm/include/asm/pgtable-3level.h b/arch/arm/include/asm/pgtable-3level.h > > index 85c60ad..b286ba9 100644 > > --- a/arch/arm/include/asm/pgtable-3level.h > > +++ b/arch/arm/include/asm/pgtable-3level.h > > @@ -207,6 +207,14 @@ static inline pmd_t *pmd_offset(pud_t *pud, unsigned long addr) > > #define pte_huge(pte) (pte_val(pte) && !(pte_val(pte) & PTE_TABLE_BIT)) > > #define pte_mkhuge(pte) (__pte(pte_val(pte) & ~PTE_TABLE_BIT)) > > > > +#define pte_special(pte) (!!(pte_val(pte) & L_PTE_SPECIAL)) > > Why the !!? Also, shouldn't this be rebased on your series adding the > pte_isset macro to ARM? Yes it should, I had this series logically separate to the pte_isset patch. I will have the pte_isset patch as a pre-requisite to the ARM fast_gup activation logic. > > > +static inline pte_t pte_mkspecial(pte_t pte) > > +{ > > + pte_val(pte) |= L_PTE_SPECIAL; > > + return pte; > > +} > > If you put this in pgtable.h based on #ifdef __HAVE_ARCH_PTE_SPECIAL, then > you can use PTE_BIT_FUNC to avoid reinventing the wheel (or define > L_PTE_SPECIAL as 0 for 2-level and have one function). Thanks, I'll give this a go. Cheers, -- Steve
next prev parent reply other threads:[~2014-06-27 12:44 UTC|newest] Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top 2014-06-25 15:40 [PATCH 0/6] RCU get_user_pages_fast and __get_user_pages_fast Steve Capper 2014-06-25 15:40 ` [PATCH 1/6] mm: Introduce a general RCU get_user_pages_fast Steve Capper 2014-06-25 15:40 ` [PATCH 2/6] arm: mm: Introduce special ptes for LPAE Steve Capper 2014-06-27 12:17 ` Will Deacon 2014-06-27 12:17 ` Will Deacon 2014-06-27 12:44 ` Steve Capper [this message] 2014-06-27 12:44 ` Steve Capper 2014-06-25 15:40 ` [PATCH 3/6] arm: mm: Enable HAVE_RCU_TABLE_FREE logic Steve Capper 2014-06-25 15:40 ` Steve Capper 2014-06-25 15:40 ` [PATCH 4/6] arm: mm: Enable RCU fast_gup Steve Capper 2014-06-25 15:40 ` [PATCH 5/6] arm64: mm: Enable HAVE_RCU_TABLE_FREE logic Steve Capper 2014-06-25 15:40 ` Steve Capper 2014-06-25 15:40 ` [PATCH 6/6] arm64: mm: Enable RCU fast_gup Steve Capper 2014-06-25 15:40 ` Steve Capper 2014-06-25 16:50 ` Mark Rutland 2014-06-25 16:50 ` Mark Rutland 2014-06-26 7:56 ` Peter Zijlstra 2014-06-26 7:56 ` Peter Zijlstra 2014-06-27 12:20 ` Will Deacon 2014-06-27 12:20 ` Will Deacon 2014-06-25 20:42 ` [PATCH 0/6] RCU get_user_pages_fast and __get_user_pages_fast Andrew Morton 2014-06-25 20:42 ` Andrew Morton 2014-06-26 7:53 ` Peter Zijlstra 2014-08-20 14:56 ` Dann Frazier 2014-08-20 15:11 ` Steve Capper
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20140627124436.GC30585@linaro.org \ --to=steve.capper@linaro.org \ --cc=Catalin.Marinas@arm.com \ --cc=akpm@linux-foundation.org \ --cc=anders.roxell@linaro.org \ --cc=christoffer.dall@linaro.org \ --cc=gary.robertson@linaro.org \ --cc=linux-arch@vger.kernel.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-mm@kvack.org \ --cc=linux@arm.linux.org.uk \ --cc=peterz@infradead.org \ --cc=will.deacon@arm.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).