Subject: Re: Excessive TLB flush ranges

From: "Russell King (Oracle)" <[email-masked]>
Date: Tue, 16 May 2023 09:27:48 +0100

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!

_______________________________________________
linux-arm-kernel mailing list
[email-masked]
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel