Hi Olivier, On 9/30/26 12:32, Olivier Kaloudoff wrote: > Hi Christian, > > On 9/30/26 12:16, Christian König wrote: >> thanks for the testing, but you are looking at outdated code. >> >> I was initially only testing with 2MiB pages and didn't see that >> issue, it is already fixed in what I've send out on Friday. >> >> Can you give that version another round of testing? The would be >> great. > > Makes sense — with 2MiB mappings the leaf-level writes dominate and the > non-leaf gap slot case barely gets exercised. Our SVM workload > (eviction/restore churn under memory pressure) hits it reliably because > it creates exactly the pattern that breaks: an unmapped gap followed by > still-linked sibling subtrees in the same parent PD. > > I just read the v2 series (the 9-patch set from the 28th) — the reworked > amdgpu_vm_pt_leaves() in patch 4/9 looks right: walking forward and > accumulating only consecutive entries that have no leaf in the same > parent is strictly better than the one-entry clamp we used locally, since > it still batches genuine gaps. And patch 2/9 explains the other half of > what we observed in RAM — the PDE_PTE-only marker (0x40000000000000) in > the clobbered slots lines up with the cleared-flag generation fix. > > Happy to re-test. I'll apply the 9-patch series on top of our 7.2.6 tree > and re-run the reproducer (vLLM/ROCm checkpoint staging on the MI50 — > previously a deterministic fault at the same stage on every run). Will > report back on the new thread.
I'm about to send out v3 of the series which can also be found here: https://gitlab.freedesktop.org/ckoenig/linux-drm/-/commits/amd-vm-svm It's based on the latest amd-staging-drm-next development branch. I have no idea if that will even apply to 7.2.6. > Two unrelated findings from the same debugging session, FYI — I'll send > them as separate mails rather than polluting this thread: > > * amdgpu_vm_fini NULL pointer dereference when the eGPU is surprise- > removed while a compute VM is being torn down (TB3 link drop under > load). Sibling of a teardown_processes NULL deref we already patched > locally. Interesting, we should have test cases for that since that is a rather common use case now. If you could give a bit more data (e.g. what timing) then Vitaly will probably be able to create a CI test case for that. > * (older, on vanilla kernels too) the SVM restore-worker livelock > under sustained reclaim — separate mail already in preparation. Yeah that is already very well known problem. The old KFD SVM code has a whole bunch of design bugs. Because of that we are working on completely replacing that with a new implementation based on the drm_gpusvm component. This patch set here is a per-requisite to that which fixes only one bug in the existing KFD implementation. Regards, Christian. > > Regards, > Olivier
