From: Dave Gordon <david.s.gordon@intel.com>
To: Daniel Vetter <daniel.vetter@ffwll.ch>,
Intel Graphics Development <intel-gfx@lists.freedesktop.org>
Cc: Daniel Vetter <daniel.vetter@intel.com>,
Thomas Gleixner <tglx@linutronix.de>,
John Stultz <john.stultz@linaro.org>
Subject: Re: [PATCH 1/2] drm/i915: compute wait_ioctl timeout correctly
Date: Fri, 28 Nov 2014 13:46:27 +0000 [thread overview]
Message-ID: <54787CB3.7000108@intel.com> (raw)
In-Reply-To: <1417166995-10803-1-git-send-email-daniel.vetter@ffwll.ch>
On 28/11/14 09:29, Daniel Vetter wrote:
> We've lost the +1 required for correct timeouts in
>
> commit 5ed0bdf21a85d78e04f89f15ccf227562177cbd9
> Author: Thomas Gleixner <tglx@linutronix.de>
> Date: Wed Jul 16 21:05:06 2014 +0000
>
> drm: i915: Use nsec based interfaces
>
> Use ktime_get_raw_ns() and get rid of the back and forth timespec
> conversions.
>
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> Signed-off-by: John Stultz <john.stultz@linaro.org>
>
> So fix this up by reinstating our handrolled _timeout function. While
> at it bother with handling MAX_JIFFIES.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82749
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: John Stultz <john.stultz@linaro.org>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> ---
> drivers/gpu/drm/i915/i915_drv.h | 10 ++++++++++
> drivers/gpu/drm/i915/i915_gem.c | 3 ++-
> 2 files changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 02b3cb32c8a6..caae337c0199 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -3030,6 +3030,16 @@ static inline unsigned long msecs_to_jiffies_timeout(const unsigned int m)
> return min_t(unsigned long, MAX_JIFFY_OFFSET, j + 1);
> }
>
> +static inline unsigned long nsecs_to_jiffies_timeout(const u64 m)
> +{
> + unsigned long j = nsecs_to_jiffies(m);
nsecs_to_jiffies() may be (relatively) expensive (mul/div/etc), so I'd
be inclined to move the call until after the test below. It would be
nice if the test turned into a single comparison, since the RHS is a
constant for a given kernel build; but it looks like jiffies_to_usecs()
isn't expanded inline, since it's in time.c :-( In which case swapping
the lines around may also help the compiler keep 'j' live.
> + if (m > (u64)jiffies_to_usecs(MAX_JIFFY_OFFSET) * 1000)
I think there's a problem with this line anyway. In kernel/time/time.c:
// Warning! Result type may be narrower than parameter type - DSG
unsigned int jiffies_to_usecs(const unsigned long j)
{
#if HZ <= USEC_PER_SEC && !(USEC_PER_SEC % HZ)
return (USEC_PER_SEC / HZ) * j;
#elif HZ > USEC_PER_SEC && !(HZ % USEC_PER_SEC)
return (j + (HZ / USEC_PER_SEC) - 1)/(HZ / USEC_PER_SEC);
#else
# if BITS_PER_LONG == 32
return (HZ_TO_USEC_MUL32 * j) >> HZ_TO_USEC_SHR32;
# else
return (j * HZ_TO_USEC_NUM) / HZ_TO_USEC_DEN;
# endif
#endif
}
Also, include/linux/jiffies.h:
#define MAX_JIFFY_OFFSET ((LONG_MAX >> 1)-1)
and include/linux/kernel.h:
#define LONG_MAX ((long)(~0UL>>1))
So, on a 64-bit build we'll have LONG_MAX == 0x7fff_ffff_ffff_ffff and
MAX_JIFFY_OFFSET == 0x3fff_ffff_ffff_fffe. Multiplying that by 1000
gives an answer that doesn't fit in an unsigned int!
Even on a 32-bit build (where LONG_MAX == 0x7fff_ffff and
MAX_JIFFY_OFFSET == 0x3fff_fffe) MAX_JIFFY_OFFSET can't be multiplied by
any typical value of HZ (50, 60, 1000) without overflow!
I think the only way to get this right, give the somewhat broken nature
of the kernel function signatures and its lack of a u64 jiffies-to-nsecs
function, is to convert ONE jiffy to (unsigned int) usecs,
then widen to u64 before converting to nsecs and using that for the rest
of the calculations.
.Dave.
> + return MAX_JIFFY_OFFSET;
> +
> + return min_t(unsigned long, MAX_JIFFY_OFFSET, j + 1);
> +}
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2014-11-28 13:46 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-28 9:29 [PATCH 1/2] drm/i915: compute wait_ioctl timeout correctly Daniel Vetter
2014-11-28 9:29 ` [PATCH 2/2] drm/i915: Handle inaccurate time conversion issues Daniel Vetter
2014-11-28 11:08 ` Chris Wilson
2014-11-28 13:30 ` Daniel Vetter
2014-11-28 12:13 ` Chris Wilson
2014-11-28 19:09 ` [PATCH 2/2] drm/i915: Handle inaccurate time conversion shuang.he
2014-12-08 12:34 ` [PATCH 2/2] drm/i915: Handle inaccurate time conversion issues Jani Nikula
2014-11-28 10:09 ` [PATCH 1/2] drm/i915: compute wait_ioctl timeout correctly Chris Wilson
2014-11-28 13:46 ` Dave Gordon [this message]
2014-12-02 14:56 ` Daniel Vetter
2014-12-02 15:22 ` [PATCH] " Daniel Vetter
2014-12-02 15:22 ` Daniel Vetter
2014-12-02 15:36 ` Daniel Vetter
2014-12-02 15:36 ` Daniel Vetter
2014-12-02 16:35 ` Chris Wilson
2014-12-02 16:35 ` [Intel-gfx] " Chris Wilson
2014-12-02 16:54 ` John Stultz
2014-12-03 9:22 ` Daniel Vetter
2014-12-03 9:22 ` [Intel-gfx] " Daniel Vetter
2014-12-03 10:28 ` Imre Deak
2014-12-03 10:28 ` [Intel-gfx] " Imre Deak
2014-12-03 14:30 ` Daniel Vetter
2014-12-03 14:30 ` [Intel-gfx] " Daniel Vetter
2014-12-03 19:07 ` John Stultz
2014-12-03 19:07 ` [Intel-gfx] " John Stultz
2014-12-04 10:42 ` Daniel Vetter
2014-12-04 10:42 ` [Intel-gfx] " Daniel Vetter
2014-12-04 17:42 ` John Stultz
2014-12-04 17:42 ` [Intel-gfx] " John Stultz
2014-12-04 17:50 ` Daniel Vetter
2014-12-04 17:50 ` [Intel-gfx] " Daniel Vetter
2014-12-04 18:16 ` John Stultz
2014-12-04 18:16 ` [Intel-gfx] " John Stultz
2014-12-04 18:51 ` Daniel Vetter
2014-12-04 18:51 ` [Intel-gfx] " Daniel Vetter
2014-12-04 20:35 ` John Stultz
2014-12-04 20:35 ` [Intel-gfx] " John Stultz
2014-12-05 9:16 ` Daniel Vetter
2014-12-05 9:16 ` [Intel-gfx] " Daniel Vetter
2014-12-03 5:21 ` shuang.he
2014-12-03 5:51 ` shuang.he
2014-12-04 10:12 ` Daniel Vetter
2014-12-04 10:12 ` Daniel Vetter
2014-12-04 17:03 ` shuang.he
2014-12-04 17:45 ` John Stultz
2014-12-04 17:45 ` John Stultz
2014-12-08 12:34 ` Jani Nikula
2014-12-08 12:34 ` [Intel-gfx] " Jani Nikula
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54787CB3.7000108@intel.com \
--to=david.s.gordon@intel.com \
--cc=daniel.vetter@ffwll.ch \
--cc=daniel.vetter@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=john.stultz@linaro.org \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.