Re: All MADV_FREE mTHPs are fully subjected to deferred_split_folio()

[David Hildenbrand <david@redhat.com>]

>> goto discard;
>>
> 
> I agree that this is necessary, but I'm not sure it addresses my
> concerns. MADV_FREE'ed mTHPs are still being added to `deferred_split`,
> and this does not resolve the issue of them being partially unmapped
> though it is definitely better than the existing code, at least folios are
> not moved back to swap-backed.
 > > On the other hand, users might rely on the `deferred_split` counter to
> assess how aggressively userspace is performing address/size unaligned
> operations
> like MADV_DONTNEED or unmapped behavior. However, our debugging shows
> that the majority of `deferred_split` counter increments result from
> aligned MADV_FREE operations. This diminishes the counter's usefulness
> in reflecting unaligned userspace behavior.

Optimizing that is certainly something to look into, but the bigger 
issue you describe arises from bad handling of speculative references.

Just imagine you indeed have a partially-mapped anon folio and the 
remaining pages are MADV_FREE'ed. The problem with the speculative 
reference would still apply.

> 
> If possible, I am still looking for some approach to entirely avoid
> adding the folio to deferred_split and partially being unmapped.
> 
> Could the concept be something like this?

Very likely it's wrong, because you really have to assure that that 
folio range is mapped here.

Proper folio PTE batching should be applied here -- folio_pte_batch() etc.

That can please the counters in many, but not all cases. Again, maybe 
the deferred-split handling should be handled differently, and not 
synchronously from rmap code.

I see 3 different work items

1) Fix mis-handling of speculative references

2) Perform proper PTE batching during unmap/migration. Will improve
    performance in any case.

3) Try moving deferred-split handling out of rmap code into reclaim/
    access-bit handling.

-- 
Cheers,

David / dhildenb