From: Rob Clark <robdclark@chromium.org>

If userspace asked for a timeout greater than zero, but less than a
jiffy, they clearly weren't planning on spinning.  So it is better
to round up to one.

This fixes an issue with supertuxkart that was (for some reason)
spinning on a gl sync with 1ms timeout.  CPU time for a demo lap
drops from:

  15.83user 20.98system 0:47.46elapsed 77%CPU

to:

  8.84user 2.30system 0:46.67elapsed 23%CPU

Signed-off-by: Rob Clark <robdclark@chromium.org>
---
 drivers/gpu/drm/msm/msm_drv.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
index 9f0c184b02a0..7936aa6cad03 100644
--- a/drivers/gpu/drm/msm/msm_drv.h
+++ b/drivers/gpu/drm/msm/msm_drv.h
@@ -548,7 +548,7 @@ static inline unsigned long timeout_to_jiffies(const ktime_t *timeout)
 		remaining_jiffies = ktime_divns(rem, NSEC_PER_SEC / HZ);
 	}
 
-	return clamp(remaining_jiffies, 0LL, (s64)INT_MAX);
+	return clamp(remaining_jiffies, 1LL, (s64)INT_MAX);
 }
 
 /* Driver helpers */
-- 
2.39.2

On Fri, 24 Mar 2023 15:00:13 -0700, Rob Clark wrote:
> If userspace asked for a timeout greater than zero, but less than a
> jiffy, they clearly weren't planning on spinning.  So it is better
> to round up to one.
> 
> This fixes an issue with supertuxkart that was (for some reason)
> spinning on a gl sync with 1ms timeout.  CPU time for a demo lap
> drops from:
> 
> [...]

Applied, thanks!

[1/1] drm/msm: Avoid rounding down to zero jiffies
      https://gitlab.freedesktop.org/lumag/msm/-/commit/a5c5593477b0

Best regards,
-- 
Dmitry Baryshkov <dmitry.baryshkov@linaro.org>

On 25/03/2023 00:00, Rob Clark wrote:
> From: Rob Clark <robdclark@chromium.org>
> 
> If userspace asked for a timeout greater than zero, but less than a
> jiffy, they clearly weren't planning on spinning.  So it is better
> to round up to one.
> 
> This fixes an issue with supertuxkart that was (for some reason)
> spinning on a gl sync with 1ms timeout.  CPU time for a demo lap
> drops from:
> 
>    15.83user 20.98system 0:47.46elapsed 77%CPU
> 
> to:
> 
>    8.84user 2.30system 0:46.67elapsed 23%CPU

Interesting. We potentially increased the timeout, but the overall 
(elapsed) time has decreased. Nevertheless:

Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>

> 
> Signed-off-by: Rob Clark <robdclark@chromium.org>
> ---
>   drivers/gpu/drm/msm/msm_drv.h | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
> index 9f0c184b02a0..7936aa6cad03 100644
> --- a/drivers/gpu/drm/msm/msm_drv.h
> +++ b/drivers/gpu/drm/msm/msm_drv.h
> @@ -548,7 +548,7 @@ static inline unsigned long timeout_to_jiffies(const ktime_t *timeout)
>   		remaining_jiffies = ktime_divns(rem, NSEC_PER_SEC / HZ);
>   	}
>   
> -	return clamp(remaining_jiffies, 0LL, (s64)INT_MAX);
> +	return clamp(remaining_jiffies, 1LL, (s64)INT_MAX);
>   }
>   
>   /* Driver helpers */

-- 
With best wishes
Dmitry

On Tue, Mar 28, 2023 at 8:28 AM Dmitry Baryshkov
<dmitry.baryshkov@linaro.org> wrote:
>
> On 25/03/2023 00:00, Rob Clark wrote:
> > From: Rob Clark <robdclark@chromium.org>
> >
> > If userspace asked for a timeout greater than zero, but less than a
> > jiffy, they clearly weren't planning on spinning.  So it is better
> > to round up to one.
> >
> > This fixes an issue with supertuxkart that was (for some reason)
> > spinning on a gl sync with 1ms timeout.  CPU time for a demo lap
> > drops from:
> >
> >    15.83user 20.98system 0:47.46elapsed 77%CPU
> >
> > to:
> >
> >    8.84user 2.30system 0:46.67elapsed 23%CPU
>
> Interesting. We potentially increased the timeout, but the overall
> (elapsed) time has decreased. Nevertheless:

There is some randomness from run to run so small variations in total
--profile-laps=N time are normal.  So I wouldn't read too much into
that, compared to %CPU.  This shouldn't really change how long it
takes for the fence to signal, as much as just prevent the CPU from
busy looping until the fence does signal ;-)

(In theory the CPU busy looping could cause GPU thermal throttling,
but I don't think that was happening in this case.)

> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>

thx

> >
> > Signed-off-by: Rob Clark <robdclark@chromium.org>
> > ---
> >   drivers/gpu/drm/msm/msm_drv.h | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
> > index 9f0c184b02a0..7936aa6cad03 100644
> > --- a/drivers/gpu/drm/msm/msm_drv.h
> > +++ b/drivers/gpu/drm/msm/msm_drv.h
> > @@ -548,7 +548,7 @@ static inline unsigned long timeout_to_jiffies(const ktime_t *timeout)
> >               remaining_jiffies = ktime_divns(rem, NSEC_PER_SEC / HZ);
> >       }
> >
> > -     return clamp(remaining_jiffies, 0LL, (s64)INT_MAX);
> > +     return clamp(remaining_jiffies, 1LL, (s64)INT_MAX);
> >   }
> >
> >   /* Driver helpers */
>
> --
> With best wishes
> Dmitry
>