Quoting Chris Wilson (2020-01-27 14:20:21) > Quoting Tvrtko Ursulin (2020-01-27 14:15:57) > > > > On 26/01/2020 10:23, Chris Wilson wrote: > > > Do an early rejection of a i915_vma_unbind() attempt if the i915_vma is > > > currently pinned, without waiting to see if the inflight operations may > > > unpin it. We see this problem with the shrinker trying to unbind the > > > active vma from inside its bind worker: > > > > What is the actual problem? flush_work from a worker? > > We hit the shrinker from the inside the worker (which is intended). But > what is not intended is for the shrinker to wait on any of the workers, > because of the potential recursion of waiting on one's self. The > intention was that we avoid the shrinker waiting on the vma by keeping > the vma pinned... But I only pinned the pages to prevent them being > freed and not the worker to prevent the recursive wait. > > Heh. Which then ties back into the whole i915_vma is not krefed, so to complete the destroy at the moment we need to sync with the workers. -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
