mmap doesn't actually stitch the file into the caller's address space right away; its lazy because that's the right answer for the vast majority of programs. S

mmap doesn't actually stitch the file into the caller's address space right away; its lazy because that's the right answer for the vast majority of programs. So when it returns with success, the caller doesn't actually have the memory in its address space. The kernel has merely promised that when a page fault happens in that range in the future that it won't deliver SIGSEGV all the way to you. You still take the faults on the access violations. And there will be many of them. Perhaps there is a set of flags to madvise that will eagerly map all of the file that is currently in the VM cache already. On the other hand, munmap must be eager. There are some page table maintenance operations which require some or all of the TLB to be flushed, because TLB's aren't cache coherent. So when the kernel replaces some page table entries with "invalid" mappings it has to nuke part of the TLB as well. Alas, in some cases the smallest unit of detonation is the entire TLB of the entire process on all cores. Until the cache warms up, every single time the process touches a new page will require a complete walk of the page tables. I only briefly peaked at the mmap crate. Looks like many of the knobs are hidden from you. Perhaps my rust-fu is weak, but I don't see any signs of support for madvise or posix_madvise except for a couple of random 0.x crates from 2017. Do I read that right - mmap is in some random 0.x crate from 2018 as well?