From: Benjamin Herrenschmidt <benh@kernel.crashing.org> To: Nick Piggin <npiggin@suse.de> Cc: Linux Memory Management <linux-mm@kvack.org>, Linux-Arch <linux-arch@vger.kernel.org>, linux-kernel@vger.kernel.org, linuxppc-dev@ozlabs.org, Hugh Dickins <hugh@tiscali.co.uk> Subject: Re: [RFC/PATCH] mm: Pass virtual address to [__]p{te,ud,md}_free_tlb() Date: Thu, 16 Jul 2009 11:54:15 +1000 [thread overview] Message-ID: <1247709255.27937.5.camel@pasglop> (raw) In-Reply-To: <20090715135620.GD7298@wotan.suse.de> On Wed, 2009-07-15 at 15:56 +0200, Nick Piggin wrote: > On Wed, Jul 15, 2009 at 05:49:47PM +1000, Benjamin Herrenschmidt wrote: > > Upcoming paches to support the new 64-bit "BookE" powerpc architecture > > will need to have the virtual address corresponding to PTE page when > > freeing it, due to the way the HW table walker works. > > > > Basically, the TLB can be loaded with "large" pages that cover the whole > > virtual space (well, sort-of, half of it actually) represented by a PTE > > page, and which contain an "indirect" bit indicating that this TLB entry > > RPN points to an array of PTEs from which the TLB can then create direct > > entries. > > RPN is PFN in ppc speak, right? Ah right, real page number in ppc slang :-) > > Thus, in order to invalidate those when PTE pages are deleted, > > we need the virtual address to pass to tlbilx or tlbivax instructions. > > Interesting arrangement. So are these last level ptes modifieable > from userspace or something? If not, I wonder if you could manage > them as another level of pointers with the existing pagetable > functions? I don't understand what you mean. Basically, the TLB contains PMD's. There's nothing to change to the existing page table layout :-) But because they appear as large page TLB entries that cover the virtual space covered by a PMD, they need to be invalidated using virtual addresses when PMDs are removed. > > The old trick of sticking it somewhere in the PTE page struct page sucks > > too much, the address is almost readily available in all call sites and > > almost everybody implemets these as macros, so we may as well add the > > argument everywhere. I added it to the pmd and pud variants for consistency. > > > > Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> > > --- > > > > I would like to merge the new support that depends on this in 2.6.32, > > so unless there's major objections, I'd like this to go in early during > > the merge window. We can sort out separately how to carry the patch > > around in -next until then since the powerpc tree will have a dependency > > on it. > > Can't see any problem with that. Thanks, can I get an Ack then ? :-) Cheers, Ben. -- 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: Benjamin Herrenschmidt <benh@kernel.crashing.org> To: Nick Piggin <npiggin@suse.de> Cc: Linux Memory Management <linux-mm@kvack.org>, Linux-Arch <linux-arch@vger.kernel.org>, linux-kernel@vger.kernel.org, linuxppc-dev@ozlabs.org, Hugh Dickins <hugh@tiscali.co.uk> Subject: Re: [RFC/PATCH] mm: Pass virtual address to [__]p{te,ud,md}_free_tlb() Date: Thu, 16 Jul 2009 11:54:15 +1000 [thread overview] Message-ID: <1247709255.27937.5.camel@pasglop> (raw) Message-ID: <20090716015415.5Otfhsra49IGj9MM74loFg4x9LkeOZSZEAx2IOmW3ak@z> (raw) In-Reply-To: <20090715135620.GD7298@wotan.suse.de> On Wed, 2009-07-15 at 15:56 +0200, Nick Piggin wrote: > On Wed, Jul 15, 2009 at 05:49:47PM +1000, Benjamin Herrenschmidt wrote: > > Upcoming paches to support the new 64-bit "BookE" powerpc architecture > > will need to have the virtual address corresponding to PTE page when > > freeing it, due to the way the HW table walker works. > > > > Basically, the TLB can be loaded with "large" pages that cover the whole > > virtual space (well, sort-of, half of it actually) represented by a PTE > > page, and which contain an "indirect" bit indicating that this TLB entry > > RPN points to an array of PTEs from which the TLB can then create direct > > entries. > > RPN is PFN in ppc speak, right? Ah right, real page number in ppc slang :-) > > Thus, in order to invalidate those when PTE pages are deleted, > > we need the virtual address to pass to tlbilx or tlbivax instructions. > > Interesting arrangement. So are these last level ptes modifieable > from userspace or something? If not, I wonder if you could manage > them as another level of pointers with the existing pagetable > functions? I don't understand what you mean. Basically, the TLB contains PMD's. There's nothing to change to the existing page table layout :-) But because they appear as large page TLB entries that cover the virtual space covered by a PMD, they need to be invalidated using virtual addresses when PMDs are removed. > > The old trick of sticking it somewhere in the PTE page struct page sucks > > too much, the address is almost readily available in all call sites and > > almost everybody implemets these as macros, so we may as well add the > > argument everywhere. I added it to the pmd and pud variants for consistency. > > > > Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> > > --- > > > > I would like to merge the new support that depends on this in 2.6.32, > > so unless there's major objections, I'd like this to go in early during > > the merge window. We can sort out separately how to carry the patch > > around in -next until then since the powerpc tree will have a dependency > > on it. > > Can't see any problem with that. Thanks, can I get an Ack then ? :-) Cheers, Ben.
next prev parent reply other threads:[~2009-07-16 1:54 UTC|newest] Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top 2009-07-15 7:49 [RFC/PATCH] mm: Pass virtual address to [__]p{te,ud,md}_free_tlb() Benjamin Herrenschmidt 2009-07-15 13:56 ` [RFC/PATCH] mm: Pass virtual address to [__]p{te, ud, md}_free_tlb() Nick Piggin 2009-07-15 13:56 ` [RFC/PATCH] mm: Pass virtual address to [__]p{te,ud,md}_free_tlb() Nick Piggin 2009-07-16 1:54 ` Benjamin Herrenschmidt [this message] 2009-07-16 1:54 ` Benjamin Herrenschmidt 2009-07-20 8:10 ` Nick Piggin 2009-07-20 10:00 ` Benjamin Herrenschmidt 2009-07-20 10:00 ` Benjamin Herrenschmidt 2009-07-20 10:38 ` Nick Piggin 2009-07-21 0:02 ` Benjamin Herrenschmidt 2009-07-21 0:02 ` Benjamin Herrenschmidt 2009-07-21 7:05 ` Nick Piggin 2009-07-20 7:11 ` Benjamin Herrenschmidt 2009-07-20 7:11 ` Benjamin Herrenschmidt 2009-07-20 7:48 ` Martin Schwidefsky 2009-07-20 7:48 ` Martin Schwidefsky 2009-07-20 8:05 ` Nick Piggin 2009-07-20 8:05 ` Nick Piggin 2009-07-20 9:59 ` Benjamin Herrenschmidt 2009-07-20 9:59 ` Benjamin Herrenschmidt 2009-07-20 10:39 ` Nick Piggin 2009-07-22 16:31 ` Linus Torvalds 2009-07-23 0:53 ` Benjamin Herrenschmidt 2009-07-23 0:59 ` Kumar Gala 2009-07-27 19:11 ` Linus Torvalds 2009-07-27 19:11 ` Linus Torvalds 2009-07-27 21:35 ` Benjamin Herrenschmidt 2009-07-27 21:35 ` Benjamin Herrenschmidt 2009-07-28 0:17 ` Benjamin Herrenschmidt 2009-07-28 0:17 ` Benjamin Herrenschmidt 2009-07-28 0:25 ` Paul Mundt 2009-07-28 0:41 ` Linus Torvalds 2009-07-28 0:41 ` Linus Torvalds 2009-07-16 1:36 ` Michael Ellerman 2009-07-16 1:56 ` Benjamin Herrenschmidt 2009-07-16 1:56 ` Benjamin Herrenschmidt 2009-07-20 12:46 ` David Howells 2009-07-20 12:46 ` David Howells
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=1247709255.27937.5.camel@pasglop \ --to=benh@kernel.crashing.org \ --cc=hugh@tiscali.co.uk \ --cc=linux-arch@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=linuxppc-dev@ozlabs.org \ --cc=npiggin@suse.de \ /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).