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

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:

quoted

On Fri, Mar 11, 2011 at 05:32:58PM +0000, Catalin Marinas wrote:

quoted

On Wed, 2011-03-09 at 18:35 +0000, Russell King - ARM Linux wrote:

quoted

On Wed, Mar 09, 2011 at 03:40:05PM +0000, Catalin Marinas wrote:

quoted

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.