On Fri, Aug 23, 2024 at 03:46:05PM +0000, Matthew Brost wrote: > On Fri, Aug 23, 2024 at 08:37:30AM +0200, Christian König wrote: > > Am 23.08.24 um 06:54 schrieb Matthew Brost: > > > Useful to preallocate dma fence array and then arm in path of reclaim or > > > a dma fence. > > > > Exactly that was rejected before because it allows to create circle > > dependencies. > > > > Can you explain or do you have link to that discussion? Trying to think > how this would be problematic and failing to see how it is. > > > You would need a really really good argument why that is necessary. > > > > It seems quite useful when you have a code path in which you know N fences > will be generated, prealloc a dma fence array, then populate at > later time ensuring no failures points (malloc), and then finally > install dma fence array in timeline sync obj (chain fences not allowed). > > It fits nicely for VM bind operations in which a device has multple > TLBs and the TLB invalidation completion is a fence. I suspect Intel > can't be the only device out their with multiple TLBs, does VM bind, and > use timeline sync obj. I think the naming you've picked is a bit confusion, since all you're splitting out is the kzalloc call. At that point the dma_fence_array isn't yet useable as a fence, so there's no issues with with circles. It's only when you call _arm that it becomes a real fence. I think just renaming _arm to _init, so that we follow the standard naming pattern for splitting _create() into kzalloc and everything else is all that's needed here? Plus updating the kernel doc to make it really clear that _alloc doesn't give you a fence, just a pile of memory. And that _init must be called with a compatible amount of fences, or it'll fail. -Sima -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
