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

Tvrtko Ursulin tvrtko.ursulin at linux.intel.com
Mon Feb 22 15:29:57 UTC 2016

On 19/02/16 15:11, Chris Wilson wrote:
> 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...

Could use kmap then and not go through the aperture? I had a patch of 
similar semantics to your vma->iomap somewhere which, to start with, 
adds ability to kmap one page. Or it could do the whole objects for 
simplicity which for LRCs should be OK.



More information about the Intel-gfx mailing list