On Thu, Feb 27, 2020 at 2:28 AM Christian KÃnig
<christian.koenig@xxxxxxx> wrote:
[SNIP]Currently (as of v2), I'm using dma_fence_array and being careful to
However, I'm not sure what the best way is to do garbage collection onExactly yes. That's also the reason why the dma_fence_chain container I
that so that we don't get an impossibly list of fence arrays.
came up with for the sync timeline stuff has such a rather sophisticated
garbage collection.
When some of the included fences signal you need to free up the
array/chain and make sure that the memory for the container can be reused.
not bother constructing one if there's only one fence in play. Is
this insufficient? If so, maybe we should consider improving
dma_fence_array.
ÂÂÂÂÂÂÂ /* Manually unlink the chain as much as possible to avoid recursion....
ÂÂÂÂÂÂÂÂ * and potential stack overflow.
ÂÂÂÂÂÂÂÂ */
ÂÂÂÂÂÂÂ while ((prev = rcu_dereference_protected(chain->prev, true))) {
I've roughly done that. The primary difference is that my version(NoteWanted to move that into dma_resv.c for quite a while since there are
the dma_resv has a lock that needs to be taken before adding an
exclusive fence, might be useful). Some code that does a thing like
this is __dma_resv_make_exclusive in
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
quite a few other cases where we need this.
takes an optional additional fence to add to the array. This makes it
a bit more complicated but I think I got it mostly right.
I've also written userspace code which exercises this and it seems to
work. Hopefully, that will give a better idea of what I'm trying to
accomplish.