On Fri, Apr 19, 2024 at 10:59 AM Pedro Falcato pedro.falcato@gmail.com wrote:
On Fri, Apr 19, 2024 at 2:22 AM Jeff Xu jeffxu@chromium.org wrote:
The overhead is likely to grow linearly with the number of VMA, since it takes time to retrieve VMA's metadata.
Let's use one data sample to look at impact:
Test: munmap 1000 memory range, each memory range has 1 VMA
syscall__ vmas t t_mseal delta_ns per_vma % munmap__ 1 909 944 35 35 104%
For those 1000 munmap calls, sealing adds 35000 ns in total, or 35 ns per call.
Have you tried to spray around some likely() and unlikely()s? Does that make a difference? I'm thinking that sealing VMAs will be very rare, and mprotect/munmapping them is probably a programming error anyway, so the extra branches in the mprotect/munmap/madvice (etc) should be a nice target for some branch annotation.
Most cost will be in locating the node in the maple tree that stores the VMAs, branch annotation is not possible there.
We could put unlikely() in the can_modify_mm check, I suspect it won't make a measurable difference in the real-world. On the other hand, this also causes no harm, and existing mm code uses unlikely/likely in a lot of places, so why not.
I will send a follow-up patch in the next few days.
Thanks -Jeff
-- Pedro