[PATCH v4 3/9] asm-generic/tlb: Avoid potential double flush

[Andrew Morton]

On Thu, 16 Jan 2020 12:19:59 +0530 "Aneesh Kumar K.V" <aneesh.kumar at linux.ibm.com> wrote:

> On 1/16/20 12:15 PM, Aneesh Kumar K.V wrote:
> > From: Peter Zijlstra <peterz at infradead.org>
> > 
> > Aneesh reported that:
> > 
> > 	tlb_flush_mmu()
> > 	  tlb_flush_mmu_tlbonly()
> > 	    tlb_flush()			<-- #1
> > 	  tlb_flush_mmu_free()
> > 	    tlb_table_flush()
> > 	      tlb_table_invalidate()
> > 		tlb_flush_mmu_tlbonly()
> > 		  tlb_flush()		<-- #2
> > 
> > does two TLBIs when tlb->fullmm, because __tlb_reset_range() will not
> > clear tlb->end in that case.
> > 
> > Observe that any caller to __tlb_adjust_range() also sets at least one
> > of the tlb->freed_tables || tlb->cleared_p* bits, and those are
> > unconditionally cleared by __tlb_reset_range().
> > 
> > Change the condition for actually issuing TLBI to having one of those
> > bits set, as opposed to having tlb->end != 0.
> > 
> 
> 
> We should possibly get this to stable too along with the first two 
> patches. I am not quiet sure if this will qualify for a stable backport. 
> Hence avoided adding Cc:stable at kernel.org

I'm not seeing any description of the user-visible runtime effects. 
Always needed, especially for -stable, please.

It appears to be a small performance benefit?  If that benefit was
"large" and measurements were presented then that would be something
we might wish to backport.