Quoting Matthew Auld (2018-05-18 12:36:30) > On 17 May 2018 at 07:03, Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> wrote: > > diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c > > index 9324d476e0a7..96039c4ef434 100644 > > --- a/drivers/gpu/drm/i915/i915_vma.c > > +++ b/drivers/gpu/drm/i915/i915_vma.c > > @@ -624,7 +624,7 @@ i915_vma_remove(struct i915_vma *vma) > > * no more VMAs exist. > > */ > > spin_lock(&i915->mm.obj_lock); > > - if (--obj->bind_count == 0) > > + if (--obj->bind_count == 0 && obj->mm.madv == I915_MADV_WILLNEED) > > How does this play with volatile objects, like gem object internal, > since they are DONTNEED while pinned? Not brilliant as they are left on the unbound_list rather than promoted to the purge_lit. They will still be reaped eventually, but I don't expect it to make any difference in practice (since they are either short lived shadow batches, or longer lived and quite-oft pinned ringbuffers). It really just means stop poking at mm.madv directly, and probably just make the decision to mark as purgeable from the start and play fewer games. -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
