Re: [PATCH] dma-buf: avoid scheduling on fence status query

["Christian König" <deathsimple@vodafone.de>]

NAK, I'm wondering how often I have to reject that change. We should 
probably add a comment here.

Even with a zero timeout we still need to enable signaling, otherwise 
some fence will never signal if userspace just polls on them.

If a caller is only interested in the fence status without enabling the 
signaling it should call dma_fence_is_signaled() instead.

Regards,
Christian.

Am 26.04.2017 um 04:50 schrieb Andres Rodriguez:
> CC a few extra lists I missed.
>
> Regards,
> Andres
>
> On 2017-04-25 09:36 PM, Andres Rodriguez wrote:
>> When a timeout of zero is specified, the caller is only interested in
>> the fence status.
>>
>> In the current implementation, dma_fence_default_wait will always call
>> schedule_timeout() at least once for an unsignaled fence. This adds a
>> significant overhead to a fence status query.
>>
>> Avoid this overhead by returning early if a zero timeout is specified.
>>
>> Signed-off-by: Andres Rodriguez <andresx7@gmail.com>
>> ---
>>
>> This heavily affects the performance of the Source2 engine running on
>> radv.
>>
>> This patch improves dota2(radv) perf on a i7-6700k+RX480 system from
>> 72fps->81fps.
>>
>>  drivers/dma-buf/dma-fence.c | 3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
>> index 0918d3f..348e9e2 100644
>> --- a/drivers/dma-buf/dma-fence.c
>> +++ b/drivers/dma-buf/dma-fence.c
>> @@ -380,6 +380,9 @@ dma_fence_default_wait(struct dma_fence *fence, 
>> bool intr, signed long timeout)
>>      if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags))
>>          return ret;
>>
>> +    if (!timeout)
>> +        return 0;
>> +
>>      spin_lock_irqsave(fence->lock, flags);
>>
>>      if (intr && signal_pending(current)) {
>>