[PATCH] dma-buf: Refanctor reservation_object_add_shared_fence()

[Christian König]

Am 30.01.2018 um 13:50 schrieb Chris Wilson:
> Quoting Christian König (2018-01-30 12:26:05)
>> Am 30.01.2018 um 10:32 schrieb Chris Wilson:
>>> Adding a shared fence to a reservation_object is currently split into
>>> two handlers, one to insert the fence into the existing array and the
>>> other to replace the existing array with a new larger array. The first
>>> step in both of these routines involves scanning the existing array to
>>> decide if it can prune any of the existing fences.
>>>
>>> As both routines perform essentially the same loop, we can combine them
>>> into one routine. During the first scan over the existing array, we
>>> search for a slot with which we can reuse for the new fence (discarding
>>> the previous). If we find no available slot to reuse, and the array is
>>> already at its max size, then we know that we need to switch to the
>>> larger array, and that no existing fence needs to be discard, they can
>>> all be copied over.
>>>
>>> add/remove: 0/0 grow/shrink: 0/3 up/down: 0/-627 (-627)
>>> Function                                     old     new   delta
>>> __warned                                    2352    2350      -2
>>> reservation_object_reserve_shared            196     185     -11
>>> reservation_object_add_shared_fence         1272     658    -614
>> Looks good to me, but still two comments:
>>
>> 1. It looks like we now can have the same context multiple times in an
>> reservation object. Could we avoid that?
> Not without scanning the entire array. Multiple fences from the same
> context isn't an issue for either of us as we both reduce down to the
> last fence on each context, and in the case of iteratively waiting on
> each fence in the reservation_object it is not noticeable.
>
> The trade-off is in choosing to scan the entire array.

So the only extra overhead is when scanning the fences during command 
submission and there it doesn't really matter if we need to handle an 
already signaled one or multiple signaled one from the same context.

Well, that is a good point.

>
>> 2. When the we copied the fences over into the new container we
>> previously removed all signaled one. That had the really nice side
>> effect of handling them during command submission quite a bit faster.
>> Can we keep that as well?
> We prove that before we copy to a new array, there are no currently
> signaled fences left.

Ah, yeah missed that. Ok in this case the patch is Reviewed-by: 
Christian König <christian.koenig at amd.com>.

Regards,
Christian.

>
> Ime, when processing the fences you generally have to discard the signaled
> fences anyway, so the benefit for add_shared_fence is in pruning any
> signaled fences to prevent realloc; and I prefer the more gradual
> approach for the trade-off in reducing the work on adding the fence.
>
> The alternative is that we basically run the replace algorithm and
> decide to the final op inplace (and not consume obj->staged) if we only
> need to replace/add one fence.
> -Chris