Quoting Dave Airlie (2020-09-14 07:27:18) > I've been trying to work out what path invalidate the vmas for the > following userspace behaviour, seen with iris/X.org but it's a bit of > a maze. > > (address are fictional) > userspace allocates bo 1, assigns it a VMA. 0x1000 > userspace allocates bo 2, assigns it a VMA 0x2000 > > Submits work with these addresses pinned > > bo 2 is freed in userspace into the userspace cache > userspace allocates bo 3 in a incompatible VMA space gets 2 from > cache, frees VMA 0x2000, allocates VMA 0x20000 > userspace alloates bo 4, assign it VMA 0x2000 > > When I get to the VMA space for BO 4 in the kernel, the VMA node is > not allocated so it's misplaced, but if you try and allocate a node, > the previous node hasn't been unbound, since the NOEVICT flags is set, > ENOSPC should return, but then does the GEM code then use relocations > and place the buffer somwhere else? It takes the slow path, upon vma insert drm_mm_reserve_node() reports ENOSPC and we then do an evict_for_node, unbind the previous occupants or report the error back to userspace for trying to use an unevictable location (which for iris should only be if it specifies the same address twice in a batch for different objects). -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
