On 08.07.24 03:46, Jason A. Donenfeld wrote:
Hi David,
Hi Jason,
just catching up on mails here. Most of the stuff is now clear from the
other subthread.
[...]
@@ -1851,7 +1858,10 @@ static bool try_to_unmap_one(struct folio *folio, struct vm_area_struct *vma,
* discarded. Remap the page to page table.
*/
set_pte_at(mm, address, pvmw.pte, pteval);
- folio_set_swapbacked(folio);
+ /* Unlike MADV_FREE mappings, VM_DROPPABLE ones
+ * never get swap backed on failure to drop. */
+ if (!(vma->vm_flags & VM_DROPPABLE))
+ folio_set_swapbacked(folio);
ret = false;
page_vma_mapped_walk_done(&pvmw);
break;
A note that in mm/mm-stable, "madvise_free_huge_pmd" exists to optimize
MADV_FREE on PMDs. I suspect we'd want to extend that one as well for
dropping support, but likely it would also only be a performance
improvmeent and not affect functonality if not handled.
That's for doing the freeing of PTEs after the fact, right? If the
mapping was created, got filled with some data, and then sometime later
it got MADV_FREE'd, which is the pattern people follow typically with
MADV_FREE. If we do this as PROT_/MAP_, then that's not a case we need
to worry about, if I understand this code correctly.
We essentially now have code to handle PMD-mapped THP: instead of first
remapping them using PTEs to then unmap+discard via 512 PTEs (due to
MADV_FREE being set on the folio), we can now simply unmap+discard a
single PMD. So performance wise, this might be interesting for this
mechanism as well (when used in combination with THP).
--
Cheers,
David / dhildenb
