Hi, > > > > Is any move buffer good enough to trigger this, i.e. will SYSTEM -> VRAM > > > > work too? That'll be easier because all I need to do is map the buffer > > > > to a crtc to force pinning to vram, then check if the mappings are > > > > intact still ... > > > > > > I think that should work too. > > > > Seems to work ok for ttm/vram. > > > > Test code: > > https://git.kraxel.org/cgit/drminfo/commit/?id=a9eb96504dc17376e07b5c6edf5296b41a48bbfe > > I think that's not nasty enough. If the mappings aren't updated, then > you'll still see the the same old pages with the right contents. You > need to change them somehow after they migrated (with vram eviction > that happens automatically since there'll b another object in the same > spot, for system memory I think you need the shrinker to kick in and > free the pages first). Easiest probably to wait for a key press so you > can appreciate the color, then write a different color (full screen) > when the buffer is in vram. 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). didn't try the memory pressure thing yet. > You'd need to check the ptes themselves. Which I think not even proc > shows by default (only the file that's supposed to be mapped). But > good to confirm that the buffer moved at least. One reproducable glitch found: fork() while having a dma-buf mapped triggers the WARN_ON in ttm_bo_vm_open(). Both old & new mmap code paths, so this isn't something new coming from the drm_gem_object_funcs.mmap switch. Instead it is an old issue coming from the address space handling being different in drm mmap and dmabuf mmap code paths. I can see now why you want a private address space for each object. Does that imply we need an anon_inode for each gem object? Or is there some more lightweight way to do this? cheers, Gerd _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel