On 11/02/16 13:29, Chris Wilson wrote:
On Thu, Feb 11, 2016 at 01:20:46PM +0000, Tvrtko Ursulin wrote:
On 11/01/16 10:45, Chris Wilson wrote:
By tracking the iomapping on the VMA itself, we can share that area
between multiple users. Also by only revoking the iomapping upon
unbinding from the mappable portion of the GGTT, we can keep that iomap
across multiple invocations (e.g. execlists context pinning).
Between the lines and from some IRC discussion it seems the goal of
this is to fix an address space memory leak with fbcon?
The goal is to prevent an issue from hastily dropping iomappings (and
vmappings elsewhere) when unpinning contexts. That comes into play when
we track the ring->vma (not just track ring->vma as we do now, but can
rely on the vma being persistent). Fixing a leak on driver unload is an
interesting side-effect.
But I don't know fbdev so can't find who would do the unpin on the
VMA to allow unbind to eventually unmap it?
That actually gets fixed in another patch when we teach intel_fbdev to
actually track the VMA it allocates, as right now we deliberately leak
it to keep the code simple.
Ok in that case ack on the patch.
It will need to assert on VMA being pinned I think and some minor
changes when you rebase it on top of nightly as standalone so I can
properly review it then.
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
