On Thu, Nov 21, 2019 at 11:18 AM Gerd Hoffmann <kraxel@xxxxxxxxxx> wrote: > > 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? Nope, not really. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
