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..
(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
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
