ACK/cmnt: [SRU Zesty][PATCH 1/1] dma-buf: avoid scheduling on fence status query v2

Kleber Souza kleber.souza at canonical.com
Thu Aug 17 16:01:40 UTC 2017


On 08/16/17 13:59, Alberto Milone wrote:
> From: Andres Rodriguez <andresx7 at gmail.com>
> 
> 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.
> 
> v2: move early return after enable_signaling
> 
> Signed-off-by: Andres Rodriguez <andresx7 at gmail.com>
> Reviewed-by: Christian K├Ânig <christian.koenig at amd.com>
> Signed-off-by: Gustavo Padovan <gustavo.padovan at collabora.com>
> Link: http://patchwork.freedesktop.org/patch/msgid/20170426144620.3560-1-andresx7@gmail.com
> 
> BugLink: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1711096
> 
> (cherry-picked from commit 03c0c5f6641533f5fc14bf4e76d2304197402552)
> Signed-off-by: Alberto Milone <alberto.milone at canonical.com>
> ---

Clean cherry pick, seems to be a reasonable performance fix.

My only comment is about the BugLink, which needs to be in the format
"http://bugs.launchpad.net/bugs/<bug-id>", and not in the expanded
format. But this can be fixed when applying the patch.

Acked-by: Kleber Sacilotto de Souza <kleber.souza at canonical.com>


>  drivers/dma-buf/dma-fence.c | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
> index 0212af7..96b3221 100644
> --- a/drivers/dma-buf/dma-fence.c
> +++ b/drivers/dma-buf/dma-fence.c
> @@ -373,6 +373,11 @@ dma_fence_default_wait(struct dma_fence *fence, bool intr, signed long timeout)
>  		}
>  	}
>  
> +	if (!timeout) {
> +		ret = 0;
> +		goto out;
> +	}
> +
>  	cb.base.func = dma_fence_default_wait_cb;
>  	cb.task = current;
>  	list_add(&cb.base.node, &fence->cb_list);
> 




More information about the kernel-team mailing list