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
