| From: |
| Rik van Riel <riel-AT-surriel.com> |
| To: |
| linux-kernel-AT-vger.kernel.org |
| Subject: |
| [PATCH v2 0/3] mm: __access_remote_vm with per-VMA lock |
| Date: |
| Wed, 24 Jun 2026 21:50:50 -0400 |
| Message-ID: |
| <20260625015053.2445008-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>, kernel-team-AT-meta.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...
v2:
- simplify the code, which should be ok because these copies are < PAGE_SIZE
- clean up the code
- fix locking wrt tlb_remove_table_sync_one()
- hopefully address all the other comments
