On Tue, Jul 21, 2009 at 10:02:26AM +1000, Benjamin Herrenschmidt wrote: > On Mon, 2009-07-20 at 12:38 +0200, Nick Piggin wrote: > > On Mon, Jul 20, 2009 at 08:00:41PM +1000, Benjamin Herrenschmidt wrote: > > > On Mon, 2009-07-20 at 10:10 +0200, Nick Piggin wrote: > > > > > > > > Maybe I don't understand your description correctly. The TLB contains > > > > PMDs, but you say the HW still logically performs another translation > > > > step using entries in the PMD pages? If I understand that correctly, > > > > then generic mm does not actually care and would logically fit better > > > > if those entries were "linux ptes". > > > > > > They are :-) > > > > > > > The pte invalidation routines > > > > give the virtual address, which you could use to invalidate the TLB. > > > > > > For PTEs, yes, but not for those PMD entries. IE. I need the virtual > > > address when destroying PMDs so that I can invalidate those "indirect" > > > pages. PTEs are already taken care of by existing mechanisms. > > > > Hmm, so even after having invalidated all the pte translations > > then you still need to invalidate the empty indirect page? (or > > maybe you don't even invalidate the ptes if they're not cached > > in a TLB). > > The PTEs are cached in the TLB (ie, they turn into normal TLB entries). > > We need to invalidate the indirect entries when the PMD value change > (ie, when the PTE page is freed) or the TLB would potentially continue > loading PTEs from a stale PTE page :-) > > Hence my patch adding the virtual address to pte_free_tlb() which is the > freeing of a PTE page. I'm adding it to the pmd/pud variants too for > consistency and because I believe there's no cost. Yes I think we're on the same page now. So as I said, the patch is quite OK with me. -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
