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.
WARNING: multiple messages have this Message-ID (diff)
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Nick Piggin <npiggin@suse.de>
Cc: Linux-Arch <linux-arch@vger.kernel.org>,
Linux Memory Management <linux-mm@kvack.org>,
Hugh Dickins <hugh@tiscali.co.uk>,
linux-kernel@vger.kernel.org, linuxppc-dev@ozlabs.org
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.
next prev parent reply other threads:[~2009-07-16 1:54 UTC|newest]
Thread overview: 74+ 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 7:49 ` Benjamin Herrenschmidt
2009-07-15 7:49 ` Benjamin Herrenschmidt
2009-07-15 7:49 ` 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-15 13:56 ` Nick Piggin
2009-07-16 1:54 ` Benjamin Herrenschmidt [this message]
2009-07-16 1:54 ` Benjamin Herrenschmidt
2009-07-16 1:54 ` Benjamin Herrenschmidt
2009-07-20 8:10 ` Nick Piggin
2009-07-20 8:10 ` Nick Piggin
2009-07-20 8:10 ` [RFC/PATCH] mm: Pass virtual address to [__]p{te, ud, md}_free_tlb() Nick Piggin
2009-07-20 10:00 ` [RFC/PATCH] mm: Pass virtual address to [__]p{te,ud,md}_free_tlb() Benjamin Herrenschmidt
2009-07-20 10:00 ` Benjamin Herrenschmidt
2009-07-20 10:00 ` Benjamin Herrenschmidt
2009-07-20 10:38 ` Nick Piggin
2009-07-20 10:38 ` Nick Piggin
2009-07-20 10:38 ` [RFC/PATCH] mm: Pass virtual address to [__]p{te, ud, md}_free_tlb() Nick Piggin
2009-07-21 0:02 ` [RFC/PATCH] mm: Pass virtual address to [__]p{te,ud,md}_free_tlb() Benjamin Herrenschmidt
2009-07-21 0:02 ` Benjamin Herrenschmidt
2009-07-21 0:02 ` Benjamin Herrenschmidt
2009-07-21 7:05 ` Nick Piggin
2009-07-21 7:05 ` Nick Piggin
2009-07-21 7:05 ` [RFC/PATCH] mm: Pass virtual address to [__]p{te, ud, md}_free_tlb() Nick Piggin
2009-07-20 7:11 ` [RFC/PATCH] mm: Pass virtual address to [__]p{te,ud,md}_free_tlb() Benjamin Herrenschmidt
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 7:48 ` Martin Schwidefsky
2009-07-20 8:05 ` Nick Piggin
2009-07-20 8:05 ` Nick Piggin
2009-07-20 8:05 ` [RFC/PATCH] mm: Pass virtual address to [__]p{te, ud, md}_free_tlb() Nick Piggin
2009-07-20 9:59 ` [RFC/PATCH] mm: Pass virtual address to [__]p{te,ud,md}_free_tlb() Benjamin Herrenschmidt
2009-07-20 9:59 ` Benjamin Herrenschmidt
2009-07-20 9:59 ` Benjamin Herrenschmidt
2009-07-20 10:39 ` Nick Piggin
2009-07-20 10:39 ` Nick Piggin
2009-07-20 10:39 ` [RFC/PATCH] mm: Pass virtual address to [__]p{te, ud, md}_free_tlb() Nick Piggin
2009-07-22 16:31 ` [RFC/PATCH] mm: Pass virtual address to [__]p{te,ud,md}_free_tlb() Linus Torvalds
2009-07-22 16:31 ` Linus Torvalds
2009-07-22 16:31 ` Linus Torvalds
2009-07-23 0:53 ` Benjamin Herrenschmidt
2009-07-23 0:53 ` Benjamin Herrenschmidt
2009-07-23 0:53 ` Benjamin Herrenschmidt
2009-07-23 0:59 ` Kumar Gala
2009-07-23 0:59 ` Kumar Gala
2009-07-23 0:59 ` [RFC/PATCH] mm: Pass virtual address to [__]p{te, ud, md}_free_tlb() Kumar Gala
2009-07-27 19:11 ` [RFC/PATCH] mm: Pass virtual address to [__]p{te,ud,md}_free_tlb() Linus Torvalds
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-27 21:35 ` Benjamin Herrenschmidt
2009-07-28 0:17 ` Benjamin Herrenschmidt
2009-07-28 0:17 ` Benjamin Herrenschmidt
2009-07-28 0:17 ` 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:25 ` Paul Mundt
2009-07-28 0:25 ` [RFC/PATCH] mm: Pass virtual address to [__]p{te, ud, md}_free_tlb() Paul Mundt
2009-07-28 0:41 ` [RFC/PATCH] mm: Pass virtual address to [__]p{te,ud,md}_free_tlb() Linus Torvalds
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:36 ` Michael Ellerman
2009-07-16 1:56 ` Benjamin Herrenschmidt
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 ` [RFC/PATCH] mm: Pass virtual address to [__]p{te, ud, md}_free_tlb() David Howells
2009-07-20 12:46 ` [RFC/PATCH] mm: Pass virtual address to [__]p{te,ud,md}_free_tlb() 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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.