On Thu, Nov 21, 2019 at 09:49:53AM +0100, Daniel Vetter wrote: > On Thu, Nov 21, 2019 at 09:02:59AM +0100, Gerd Hoffmann wrote: > > Hi, > > > > > > update-object-after-move works fine. > > > > > > > > try zap mappings with madvise(dontneed) has no bad effects (after vram > > > > move, trying to force re-creating the ptes). > > > > > > Well if it's broken the zapping wouldn't work :-) > > > > > > > didn't try the memory pressure thing yet. > > > > > > I'm surprised ... and I have no idea how/why it keeps working. > > > > > > For my paranoia, can you instrument the ttm page fault handler, and double > > > check that we get new faults after the move, and set up new ptes for the > > > same old mapping, but now pointing at the new place in vram? > > > > Hmm, only the drm device mapping is faulted in after moving it, > > the dma-buf mapping is not. Fixed by: > > Ah yes, that's more what I'd expect to happen, and the below is what I'd > expect to fix things up. I think we should move it up ahead of the device > callback (so that drivers can overwrite) and then push as a fix. Separate > from a possible patch to undo the fake offset removal. > -Daniel Is there a more elegant way than copying the intel list on non-intel patches to kick intel ci? cheers, Gerd _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
