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

[Rob Clark]

On Sun, Oct 16, 2016 at 1:49 PM, Chris Wilson <chris at chris-wilson.co.uk> 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..

(although I probably also need to move the fence_put() from
fence_array_cb_func() to the worker fxn)

>> +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.

ahh, yeah, that makes sense..

BR,
-R

> -Chris
>
> --
> Chris Wilson, Intel Open Source Technology Centre