On 24/11/15 13:27, Chris Wilson wrote:
On Tue, Nov 24, 2015 at 01:17:57PM +0000, Tvrtko Ursulin wrote:
On 24/11/15 12:53, Chris Wilson wrote:
On Tue, Nov 24, 2015 at 11:58:22AM +0100, Daniel Vetter wrote:
On Fri, Nov 20, 2015 at 01:23:36PM +0000, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx>
Commit e9f24d5fb7cf3628b195b18ff3ac4e37937ceeae
Author: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx>
Date: Mon Oct 5 13:26:36 2015 +0100
drm/i915: Clean up associated VMAs on context destruction
Added a warning based on an incorrect assumption that all VMAs
in a VM will be on the inactive list at the point last reference
to a context and VM is dropped.
This is not true because i915_gem_object_retire__read will not
put VMA on the inactive list until all activities on the object
in question (in all VMs) have been retired.
As a consequence, whether or not a context/VM will be destroyed
with its VMAs still on the active list, can depend on completely
unrelated activities using the same object from a different
context or engine.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92638
Testcase: igt/gem_request_retire/retire-vma-not-inactive
Cc: Daniel Vetter <daniel.vetter@xxxxxxxx>
Cc: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
Cc: Michel Thierry <michel.thierry@xxxxxxxxx>
Queued for -next, thanks for the patch.
The WARN_ON is accurate though. The original patch fails to fix even the
limited aspect of the bug it claimed to.
That is not true. It only makes it a bit more limited, and not by
its fault even. Even with that it makes things a bit better, not
worse.
It makes the code worse for very limited improvement, for which we did
not have a publically reported bug, i.e. the impact is very small.
Well impact was huge for Android userspace but you are probably right
that BZ was not created for that.
It was somewhat related to
https://bugs.freedesktop.org/show_bug.cgi?id=87477 on small memory
configurations if I remember correctly. Although that hasn't been
correctly captured in there or a new entry forked off.
We have on the other hand added an IGT for it
gem_ppgtt/flink-and-close-vma-leak so I don't think your argument is fair.
Especially if the rewrite of it all is imminent - so the worse code,
even if you think it is so much worse which I disagree with, is only in
there temporary.
And the memory leak was real even with fbcon and Xorg which I am sure
you know.
And does not impede your VMA rewrite at all. For which I did offer
help to review as you send out in manageable chunks.
I have been.
And I have reviewed some, no? Feel free to ping me if I missed some.
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
