[RFC PATCH 2/2] ARMv7: Invalidate the TLB before freeing page tables

[linux@arm.linux.org.uk (Russell King - ARM Linux)]

On Mon, Mar 14, 2011 at 11:15:45AM +0000, Catalin Marinas wrote:
> On Fri, 2011-03-11 at 19:24 +0000, Russell King - ARM Linux wrote:
> > On Fri, Mar 11, 2011 at 05:32:58PM +0000, Catalin Marinas wrote:
> > > On Wed, 2011-03-09 at 18:35 +0000, Russell King - ARM Linux wrote:
> > > > On Wed, Mar 09, 2011 at 03:40:05PM +0000, Catalin Marinas wrote:
> > > > > The above call to tlb_add_flush() would only add a PAGE_SIZE. But
> > > > > since we free an entire PTE, shouldn't the range cover addr ..
> > > > > addr+PTRS_PER_PTE*PAGE_SIZE?
> > > >
> > > > Why do we need to?  We're not flushing away the individual PTE entries
> > > > when we remove an entire page table - we will have already walked the
> > > > page table removing those entries, which will already have been added.
> > >
> > > Ah, I missed the fact that tlb_flush() invalidates the whole TLB when
> > > there is no tlb->vma (the shift_arg_pages case). We could optimise this
> > > to add the range covered by the PTE page and avoid the !tlb->vma check
> > > (and a flush_tlb_mm), though not sure it's worth.
> > 
> > If we're removing pte entries then tlb->vma is non-NULL.  Please look at
> > the comments - I've documented the three modes of use there along with
> > how things are setup for each of those modes, and what we do with each.
> 
> Yes, I read them (they are useful) and I was only referring to point 3
> in the comments, shift_arg_pages(). In this case tlb->vma is NULL and we
> flush the full mm in tlb_flush(). Can we have a smaller address range
> since we can get the from pte_free_tlb()?
> 
> This would mean removing the !tlb->vma check in tlb_flush() and change
> tlb_add_flush() to take a range rather than just an address.

And the reason for doing so being what exactly?

We have very little in the way of userspace TLB entries (we shouldn't have
any other than for the existing arg pages).  So I don't see any benefit to
issuing several individual page TLB invalidates over a range for the arg
pages vs issuing one TLB invalidate for the entire ASID.

The latter seems to me to be the most efficient solution.