Two processes share a set of buffers, and each has buffers of its own which the other never sees. Say process A has mapped
S the shared buffers, also mapped by B P buffers private to A and B has mapped S plus private buffers of its own. The overlap is exactly S, and the work each process wants to do on its own buffers is independent of the other. A submits. Its exec locks the dma-resv of everything it has mapped, S and P both, then finds something in P has been evicted and migrates it back in. B submits, and blocks on S for as long as that migration takes, even though the migration is of a buffer belonging to A which B has never seen. So the stall does not come from the overlapping set. The buffers in S are resident, and neither exec has anything to do to them beyond attaching a fence. They are held only because an exec locks everything it has mapped in one go, and they stay held until the slowest unrelated thing in that transaction is done. Which buffers get evicted is a separate matter, and one which already has answers: eviction heuristics which leave shared buffers alone, or one process' allocations outranking another's. This is what is left once those work. Where this tends to show up is compositors and presentation, which is also where userspace has worked hardest to avoid it. Wayland explicit sync exists so that a compositor is not latched onto its clients' rendering, waiting on fences it never asked for. The locking above reintroduces that coupling anyway, in the kernel, and does it under memory pressure, which is where a missed frame is least welcome and the cause is hardest to see. The fix is to stop coupling "lock the VM" to "validate it". Instead of locking everything and then validating, lock the private buffers and the evicted external ones, validate those, and only then lock the rest, all within the same drm_exec transaction. Patch 1 lets a driver split the locking of an exec that way, patches 2 and 3 use it in Xe and Panthor, whose panthor_vm_bo_validate() swaps pages back in under those same shared locks. It is opt-in, and drivers which do not ask for it are unaffected. Matt Cc: Alice Ryhl <[email protected]> Cc: Boris Brezillon <[email protected]> Cc: Danilo Krummrich <[email protected]> Cc: David Airlie <[email protected]> Cc: Jonathan Corbet <[email protected]> Cc: Liviu Dudau <[email protected]> Cc: Maarten Lankhorst <[email protected]> Cc: Maxime Ripard <[email protected]> Cc: Rodrigo Vivi <[email protected]> Cc: Shuah Khan <[email protected]> Cc: Simona Vetter <[email protected]> Cc: Steven Price <[email protected]> Cc: Thomas Hellström <[email protected]> Cc: Thomas Zimmermann <[email protected]> Signed-off-by: Matthew Brost <[email protected]> Assisted-by: GitHub_Copilot:claude-opus-5 Matthew Brost (3): drm/gpuvm: allow locking external objects in two passes drm/xe: lock the resident BOs of an exec last drm/panthor: lock the resident BOs of a submit last Documentation/gpu/drm-mm.rst | 6 + drivers/gpu/drm/drm_gpuvm.c | 480 +++++++++++++++++++++++++- drivers/gpu/drm/panthor/panthor_mmu.c | 53 ++- drivers/gpu/drm/xe/xe_exec.c | 23 +- drivers/gpu/drm/xe/xe_vm.c | 43 ++- drivers/gpu/drm/xe/xe_vm.h | 3 +- include/drm/drm_gpuvm.h | 133 ++++++- 7 files changed, 709 insertions(+), 32 deletions(-) -- 2.34.1
