On Fri, Apr 19, 2024 at 10:59 AM Pedro Falcato <pedro.falcato@xxxxxxxxx> wrote: > > On Fri, Apr 19, 2024 at 2:22 AM Jeff Xu <jeffxu@xxxxxxxxxxxx> 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
