Re: [PATCH v3 0/2] attempt to map anonymous pte-mapped THPs by pmds

[David Hildenbrand <david@redhat.com>]

On 21.12.23 21:40, Zach O'Keefe wrote:
> Hey Xu,
> 
> Thanks for the patches.
> 
> As a precursor, can you help understand what the use case is for these
> patches? In-place collapse of anon memory is something I've thought
> about before, but the opportunity has never been especially clear.
> 
> In particular, your patches take an order-9 compound page, and just
> try to see if we can update the mappings to it (like we do with
> file/shmem). Functionally this seems fine, but the difference is that
> with file/shmem, it's quite easy to have a pte-mapped-hugepage arise
> naturally (the formation of the hugepage happening in the pagecache
> being logically separate from the pmd-mapping of w/e task is mapping
> it).\
> 
> For anonymous memory, the only time I can see us having a pte-mapped
> hugepage (that isn't destined for splitting on deferred split list)
> that we want to remap by a pmd is if we cause a VMA split + remerge by
> mucking with VMA attributes.

Yes, mostly because of madvise(), mprotect(), mremap(). But also, when 
putting a THP into the swap cache right now. When refaulting, you get a 
PTE-mapped THP.

There are some other odd cases, and there might be more in the future 
(below)

> 
> In my mind, what I had been thinking of w.r.t in-place anon collapse
> was for the case where we've split a THP with MADV_FREE/MADV_DONTNEED
> (i.e. to subrelease pages back to kernel), but later want to reform
> the THP. In particular, if, for example, we only subrelease O(10s) of

Right, and in-place collapse even works if the folio has been pinned, 
which is nice.

> order-0 pages, it seems wasteful to have to reallocate a fresh
> hugepage, then copy over O(100s) of pages, on collapse. If we were
> able to attempt to first migrate-away any of those previously
> subreleased pages (now possibly backing some other memory entirely),
> it could save us from having to allocate a fresh order-9 page. Under
> memory pressure / fragmentation, this could mean the difference
> between success and failure.
> 

One thing that popped up a couple of times already is that we might want 
to PTE-map a PMD-sized THP for a couple of reasons (IIRC, FreeBSD does 
some of that). For example:

* Lazily zero the pages of the folio on demand, keeping all non-zeroed
   parts protnone. At a certain time (e.g., all zeroed), simply remap
   using a PMD.
* Detecting sub-page access by temporarily mapping the THP using PTEs.

Maybe, also some uffd optimizations, whereby protnone parts are not 
faulted in yet.

-- 
Cheers,

David / dhildenb