On Sun, Oct 16, 2016 at 02:29:51PM -0400, Rob Clark wrote: > On Sun, Oct 16, 2016 at 1:49 PM, Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> wrote: > > On Sun, Oct 16, 2016 at 12:39:35PM -0400, Rob Clark wrote: > >> This is the alternative approach for solving a deadlock situation with > >> array-fences. > >> > >> Currently with fence-array, we have a potential deadlock situation. If we > >> fence_add_callback() on an array-fence, the array-fence's lock is aquired > >> first, and in it's ->enable_signaling() callback, it will install cb's on > >> it's array-member fences, so the array-member's lock is acquired second. > >> > >> But in the signal path, the array-member's lock is acquired first, and the > >> array-fence's lock acquired second. > > > > I'm feeling this is the better approach, it puts the complexity inside > > the trickster. However, I think it is better to move the wq to > > enable-signaling rather than the fence_signal() cb. (Latency at the > > start of the wait will hopefully be absorbed by the wait, but we cannot > > hide latency at the end). > > my spidey sense is telling me that would race with the fence getting signalled.. Which we don't care about, since we haven't yet added ourselves to the cb_list of the fence so haven't yet adjusted the fence-array's pending count and so haven't yet signaled the fence array. i.e. we can tolerate enabling signaling on the fence array after all of its children are signaled. Imo, better to have that latency upfront. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
