Re: [PATCH v10 00/12] LUF(Lazy Unmap Flush) reducing tlb numbers over 90%

[Dave Hansen]

On 5/26/24 20:10, Huang, Ying wrote:
>> Thank you for the pointing out.  I will fix it too by introducing a new
>> flag in inode or something to make LUF aware if updating the file has
>> been tried so that LUF can give up and flush right away in the case.
>>
>> Plus, I will add another give-up at code changing the permission of vma
>> to writable.
> I guess that you need a framework similar as
> "flush_tlb_batched_pending()" to deal with interaction with other TLB
> related operations.

Where "other TLB related operations" includes both things that
traditionally invalidate TLBs (like going Present 1=>0) and things like
fault-in that go Present 0=>1 that can result in TLB population.

It's actually a really crummy problem to solve.  We don't have _any_
machinery to say, "Hey, you know that PTE you wanted to install?  There
was something there before you and we haven't flushed it yet.  Can you
be a doll and do a flush before _populating_ that PTE?"

To solve it generically, I suspect you'll need some kind of special
non-present PTE to say:

	There _was_ a PTE here that wasn't flushed.

Sure, you can add gunk to the VMA to track when this happens.  But
that'll penalize anyone populating a PTE anywhere in the VMA at least
once.  If there were other threads faulting in pages to the same VMA,
they'll just end up doing the flush that LUF tried to avoid in the first
place.