[markjdb]

> I do wonder why there isn't an API for "lazy munmap()"

You don't really need a separate API. The kernel can implement munmap() lazily, it just needs to also ensure that the address range isn't reused until a TLB shootdown is completed. LATR is a system that leverages this to implement lazy TLB shootdowns for munmap(): http://www.cs.yale.edu/homes/abhishek/kumar-asplos18.pdf

[BeeOnRope]

Wouldn't this break the existing semantics of mmap, which is after the mmap call returns, other threads in the same process will fault if the they access the mapping?

Sure, avoiding re-use prevents some types of bugs but not others.

[londons_explore]

Id be interested to know if any program relies on freeing memory in one thread, then (with some lock for synchronization) deliberately accessing it from another thread causing a segfault.

Sure, it's possible, but if no programs do it, it might be worth breaking the behaviour for the performance increase.

[kentonv]

If the program is just using mmap/munmap for memory allocation, then I agree with you.

But some programs do crazier things. Imagine a program that implements mmap of a file entirely in userspace. For example, say I have a file that's stored on a distributed filesystem that dosen't have kernel drivers. So I catch SIGSEGV in userspace and populate pages on-demand by fetching them from the remote server. Later on, the page hasn't been used in a while, so I munmap() it to reclaim memory. I expect that any further uses after this point (especially writes, which maybe I need to sync back?) will raise a new SIGSEGV which I can handle.

I think something like that, unfortunately, could be broken by changing all munmaps to be lazy...

[markjdb]

I was wondering how this scheme might break applications that do clever things with a SIGBUS/SIGSEGV handler. Do you happen to know of any OSS that actually does something like this?

[saagarjha]

FUSE?