Excessive TLB flush ranges

[Thomas Gleixner]

On Tue, May 16 2023 at 11:03, Thomas Gleixner wrote:
> On Tue, May 16 2023 at 09:27, Russell King wrote:
>> 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.
>
> Something like the untested below?

The list based individual flush wins over a tlb_flush_all() in that
particular scenario. It's almost in the noise while the TLB flush all
has an impact of ~1% on the other CPUs computation runtime.

That's just a quick check w/o deeper analysis, but that clearly shows
that there is potential.

Whether the list or as Nadav suggested some other storage turns out to
be also benefitial for IPI based flushing is still subject to
investigation.

Thanks,

        tglx