| From: |
| Rik van Riel <riel-AT-surriel.com> |
| To: |
| linux-kernel-AT-vger.kernel.org |
| Subject: |
| [PATCH 0/3] mm: __access_remote_vm with per-VMA lock |
| Date: |
| Tue, 16 Jun 2026 15:02:57 -0400 |
| Message-ID: |
| <20260616190300.1509639-1-riel@surriel.com> |
| Cc: |
| Rik van Riel <riel-AT-surriel.com>, x86-AT-kernel.org, linux-mm-AT-kvack.org, "Thomas Gleixner" <tglx-AT-kernel.org>, "Ingo Molnar" <mingo-AT-redhat.com>, "Dmitry Ilvokhin" <d-AT-ilvokhin.com>, "Borislav Petkov" <bp-AT-alien8.de>, "Dave Hansen" <dave.hansen-AT-linux.intel.com>, "Andrew Morton" <akpm-AT-linux-foundation.org>, "David Hildenbrand" <david-AT-kernel.org>, "Lorenzo Stoakes" <ljs-AT-kernel.org>, "Liam R. Howlett" <liam-AT-infradead.org>, "Vlastimil Babka" <vbabka-AT-kernel.org>, "Suren Baghdasaryan" <surenb-AT-google.com> |
| Archive-link: |
| Article |
Sometimes processes can get stuck with the mmap_lock held for
a long time. This slows down, and can even prevent system monitoring
tools from assessing and logging the situation, because they themselves
end up getting stuck on the mmap_lock.
However, with the introduction of per-VMA locks, we can improve the
reliability of system monitoring, and generally speed up __access_remote_vm
under mmap_loc contention, by adding a fast path that does not require
the process-wide mmap_lock.
This fast path is only compiled in and used when it is safe to do so,
meaning a kernel with per-VMA locks, RCU pgae table freeing, the VMA
is not hugetlbfs, iomap, pfnmap, etc...
The code seems to work, but could still use some more cleaning up
and benchmarking.
