On Mon, 5 Aug 2024 at 23:05, Oliver Sang <oliver.sang@xxxxxxxxx> wrote:
>
> > New version - still untested, but now I've read through it one more
> > time - attached.
>
> we tested this version by applying it directly upon 8be7258aad, but seems it
> have little impact to performance. still similar regression if comparing to
> ff388fe5c4.
Note that that patch (and Michael's fixes for ppc on top) in itself
doesn't fix any performance issue.
But getting rid of arch_unmap() means that now the can_modify_mm() in
do_vmi_munmap() is right above the "vma_find()" (and can in fact be
moved below it and into do_vmi_align_munmap), and that means that at
least the unmap paths don't need the vma lookup of can_modify_mm() at
all, because they've done their own.
IOW, the "arch_unmap()" removal was purely preparatory and did nothing
on its own, it's only preparatory to get rid of some of the
can_modify_mm() costs.
The call to can_modify_mm() in mremap_to() is a bit harder to get rid
of. Unless we just say "mremap will unmap the destination even if the
mremap source is sealed".
Linus
