(adding dri-devel) On Mon, Sep 23, 2024 at 02:24:02PM +0000, Zeng, Oak wrote: > > > This patch is an old one in my back log. I roughly remember I ran into > > a situation where there were two duplicated VMAs covering > > > Same virtual address range are kept in gpuvm's RB-tree. One VMA > > was actually already destroyed. This further caused issues as > > > The destroyed VMA was found during a GPUVM RB-tree walk. This > > triggered me to look into the gpuvm merge split logic and end > > > Up with this patch. This patch did fix that issue. > > > > That would indeed be a big issue. As Matt suggests, is there a > > reproducer? > > > > Either way, adding merge support can't be the fix for this, we need a > > separate > > one, that's back-portable. > > > > The discussion went on when you were away. See https://patchwork.freedesktop.org/patch/614941/?series=138835&rev=1 Yes, I'm aware. But I don't see how this is related to what I said above? > > Matt and me agreed to implement a merge logic in gpuvm, but gpuvm need to check a driver cookie/callback to decide merge or not. > We reached this conclusion based on some requirement from system allocator design. See more details in above link. > > Can you take a look and let us know whether you agree? Generally, I'm fine with that, one of my early versions of GPUVM had this. But I dropped it because I don't saw an immediate benefit.
