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

Andrew Morton
2020-01-17T01:46:29Z

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

> On 1/16/20 12:15 PM, Aneesh Kumar K.V wrote:
> > From: Peter Zijlstra <peterz@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@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.