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).
> +static int __init fence_array_init(void)
> +{
> + fence_array_wq = alloc_ordered_workqueue("fence-array", 0);
> + if (!fence_array_wq)
> + return -ENOMEM;
Defintely doesn't want to be ordered, since the fences put onto the wq
should be independent and can work in parallel. system_unbound should
suffice.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
