[Intel-gfx] [PATCH 136/190] drm/i915: Move ioremap_wc tracking onto VMA

[Chris Wilson]

On Thu, Feb 11, 2016 at 02:10:19PM +0000, Tvrtko Ursulin wrote:
> 
> 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.

Had some more fun recently where the iomap was showing up again, and
realised that for 64b systems we can keep a pointer to inside our
dev_priv->gtt.mappable iomapping. Makes the patch a little more ugly
(requires #ifdeffry) but eliminates all of the runtime iomapping
overhead!

However, that wasn't enough for the test case as the limitation to the
mappable aperture was too severe...
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre