[PATCH] dma-buf: Refanctor reservation_object_add_shared_fence()

[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.

> 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.

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