[RFC] dma-buf/fence-array: signal from wq

[Chris Wilson]

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