Re: [PATCH 08/20] mm: Optimize fullmm TLB flushing

[Catalin Marinas <catalin.marinas@arm.com>]

On Thu, Jun 28, 2012 at 11:59:56AM +0100, Peter Zijlstra wrote:
> On Thu, 2012-06-28 at 20:39 +1000, Benjamin Herrenschmidt wrote:
> > On Thu, 2012-06-28 at 10:16 +0100, Catalin Marinas wrote:
> > > That's definitely an issue on ARM and it was hit on older kernels.
> > > Basically ARM processors can cache any page translation level in the
> > > TLB. We need to make sure that no page entry at any level (either cached
> > > in the TLB or not) points to an invalid next level table (hence the TLB
> > > shootdown). For example, in cases like free_pgd_range(), if the cached
> > > pgd entry points to an already freed pud/pmd table (pgd_clear is not
> > > enough) it may walk the page tables speculatively cache another entry in
> > > the TLB. Depending on the random data it reads from an old table page,
> > > it may find a global entry (it's just a bit in the pte) which is not
> > > tagged with an ASID (application specific id). A latter flush_tlb_mm()
> > > only flushes the current ASID and doesn't touch global entries (used
> > > only by kernel mappings). So we end up with global TLB entry in user
> > > space that overrides any other application mapping.
> > 
> > Right, that's the typical scenario. I haven't looked at your flush
> > implementation though, but surely you can defer the actual freeing so
> > you can batch them & limit the number of TLB flushes right ?
> 
> Yes they do.. its just the up-front TLB invalidate for fullmm that's a
> problem.

The upfront invalidate is fine (i.e. harmless), it's the tlb_flush_mmu()
change to check for !tlb->fullmm that's not helpful on ARM.

-- 
Catalin

--
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>