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

[Tvrtko Ursulin]

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.

Regards,

Tvrtko