Re: Excessive TLB flush ranges

Russell King (Oracle)
2023-05-16T08:28:22Z

On Tue, May 16, 2023 at 10:20:37AM +0200, Thomas Gleixner wrote:
> On Tue, May 16 2023 at 10:18, Thomas Gleixner wrote:
>
> > On Tue, May 16 2023 at 08:37, Thomas Gleixner wrote:
> >> On Mon, May 15 2023 at 22:31, Russell King wrote:
> >>>> + list_for_each_entry(va, list, list) {
> >>>> + /* flush range by one by one 'invlpg' */
> >>>> + for (addr = va->va_start; addr < va->va_end; addr += PAGE_SIZE)
> >>>> + flush_tlb_one_kernel(addr);
> >>>
> >>> Isn't this just the same as:
> >>> flush_tlb_kernel_range(va->va_start, va->va_end);
> >>
> >> Indeed.
> >
> > Actually not. At least not on x86 where it'd end up with 3 IPIs for that
> > case again, instead of having one which walks the list on each CPU.
>
> ARM32 has the same problem when tlb_ops_need_broadcast() is true.

If tlb_ops_need_broadcast() is true, then isn't it one IPI to other
CPUs to flush the range, and possibly another for the Cortex-A15
erratum?

I've no idea what flush_tlb_one_kernel() is. I can find no such
implementation, there is flush_tlb_kernel_page() though, which I
think is what you're referring to above. On ARM32, that will issue
one IPI each time it's called, and possibly another IPI for the
Cortex-A15 erratum.

Given that, flush_tlb_kernel_range() is still going to be more
efficient on ARM32 when tlb_ops_need_broadcast() is true than doing
it page by page.

--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!