Re: Excessive TLB flush ranges

[Thomas Gleixner <tglx@linutronix.de>]

On Tue, May 16 2023 at 15:42, Uladzislau Rezki wrote:
>> _vm_unmap_aliases() collects dirty ranges from per cpu vmap_block_queue
>> (what ever that is) and hands a start..end range to
>> __purge_vmap_area_lazy().
>> 
>> As I pointed out already, this can also end up being an excessive range
>> because there is no guarantee that those individual collected ranges are
>> consecutive. Though I have no idea how to cure that right now.
>> 
>> AFAICT this was done to spare flush IPIs, but the mm folks should be
>> able to explain that properly.
>> 
> This is done to prevent generating IPIs. That is why the whole range is
> calculated once and a flush occurs only once for all lazily registered VAs.

Sure, but you pretty much enforced flush_tlb_all() by doing that, which
is not even close to correct.

This range calculation is only correct when the resulting coalesced
range is consecutive, but if the resulting coalesced range is huge with
large holes and only a few pages to flush, then it's actively wrong.

The architecture has zero chance to decide whether it wants to flush
single entries or all in one go.

There is a world outside of x86, but even on x86 it's borderline silly
to take the whole TLB out when you can flush 3 TLB entries one by one
with exactly the same number of IPIs, i.e. _one_. No?

Thanks,

        tglx