[Intel-gfx] [PATCH 17/37] drm/i915: Track vma activity per fence.context, not per engine

[Tvrtko Ursulin]

On 29/06/2018 16:39, Chris Wilson wrote:
> Quoting Chris Wilson (2018-06-29 16:36:22)
>> Quoting Tvrtko Ursulin (2018-06-29 16:08:40)
>>>
>>> On 29/06/2018 15:54, Tvrtko Ursulin wrote:
>>>
>>> [snip]
>>>
>>>>> +int i915_vma_move_to_active(struct i915_vma *vma,
>>>>> +                struct i915_request *rq,
>>>>> +                unsigned int flags)
>>>>> +{
>>>>> +    struct drm_i915_gem_object *obj = vma->obj;
>>>>> +    struct i915_gem_active *active;
>>>>> +
>>>>> +    lockdep_assert_held(&rq->i915->drm.struct_mutex);
>>>>> +    GEM_BUG_ON(!drm_mm_node_allocated(&vma->node));
>>>>> +
>>>>> +    active = lookup_active(vma, rq->fence.context);
>>>>
>>>> Never mind the radix tree, but fence.context is u64 as well. And
>>>> assigned values are continuously incrementing so once >4G of contexts
>>>> are created and destroyed aliasing is guaranteed with the kernel
>>>> context, or any old one.
>>>>
>>>> It is probably IGT abuse territory, but a) can we be sure it will not
>>>> open up some exploit, and b) can we swallow this problem ourselves?
>>>
>>> Hm.. key the radix tree with the timeline pointer instead? 1:1 to
>>> fence.context, natural long, and automatic lifetime management.
>>
>> Lets see.
> 
> Counter argument is density. timeline pointers are going to be much
> sparser than my expectations around context id (even with the silly
> incrementing u64).

Or maybe something built from the basis of i915_syncmap? Same keys and 
same lifetime, just the stored data is different.

Regards,

Tvrtko