quoted

I do wonder which purpose the deferred split serves nowadays at all.
Fortunately, there is documentation: Documentation/vm/transhuge.rst:

"
Unmapping part of THP (with munmap() or other way) is not going to free
memory immediately. Instead, we detect that a subpage of THP is not in
use in page_remove_rmap() and queue the THP for splitting if memory
pressure comes. Splitting will free up unused subpages.

Splitting the page right away is not an option due to locking context in
the place where we can detect partial unmap. It also might be
counterproductive since in many cases partial unmap happens during
exit(2) if a THP crosses a VMA boundary.

The function deferred_split_huge_page() is used to queue a page for
splitting. The splitting itself will happen when we get memory pressure
via shrinker interface.
"

I do wonder which these locking contexts are exactly, and if we could
also do the same thing on ordinary munmap -- because I assume it can be
similarly problematic for some applications.

This is a good question regarding munmap. One main difference is
munmap takes mmap_lock in write mode and usually performance critical
applications avoid such operations.

Maybe we can extend it too most page zapping, if that makes things simpler.

quoted

The "exit()" case might
indeed be interesting, but I really do wonder if this is even observable
in actual number: I'm not so sure about the "many cases" but I might be
wrong, of course.

I am not worried about the exit(). The whole THP will get freed and be
removed from the deferred list as well. Note that deferred list does
not hold reference to the THP and has a hook in the THP destructor.

Yes, you're right. We'll run into the de-constructor either way.

-- 
Thanks,

David / dhildenb