On Tue, May 23 2023 at 17:27, Christoph Hellwig wrote:
> On Tue, May 23, 2023 at 04:02:13PM +0200, Thomas Gleixner wrote:
>> vmap blocks which have active mappings cannot be purged. Allocations which
>> have been freed are accounted for in vmap_block::dirty_min/max, so that
>> they can be detected in _vm_unmap_aliases() as potentially stale TLBs.
>>
>> If there are several invocations of _vm_unmap_aliases() then each of them
>> will flush the dirty range. That's pointless and just increases the
>> probability of full TLB flushes.
>>
>> Avoid that by resetting the flush range after accounting for it. That's
>> safe versus other invocations of _vm_unmap_aliases() because this is all
>> serialized with vmap_purge_lock.
>
> Just nitpicking, but isn't vb->lock the actually relevant lock here?
> vmap_purge_lock is only taken after the loop.
No. The avoid double list iteration change moves the purge lock up
before the loop as it needs to protect against a concurrent purge
attempt.
Thanks,
tglx
