From: Imre Deak <imre.deak@intel.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>,
Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
LKML <linux-kernel@vger.kernel.org>,
John Stultz <john.stultz@linaro.org>,
Daniel Vetter <daniel.vetter@intel.com>,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH] drm/i915: compute wait_ioctl timeout correctly
Date: Wed, 03 Dec 2014 12:28:14 +0200 [thread overview]
Message-ID: <1417602494.2642.0.camel@intelbox> (raw)
In-Reply-To: <20141203092216.GZ32117@phenom.ffwll.local>
On Wed, 2014-12-03 at 10:22 +0100, Daniel Vetter wrote:
> On Tue, Dec 02, 2014 at 08:54:13AM -0800, John Stultz wrote:
> > On Tue, Dec 2, 2014 at 8:35 AM, Chris Wilson <chris@chris-wilson.co.uk> wrote:
> > > On Tue, Dec 02, 2014 at 04:36:22PM +0100, Daniel Vetter wrote:
> > >> +static inline unsigned long nsecs_to_jiffies_timeout(const u64 m)
> > >> +{
> > >> + u64 usecs = div_u64(m + 999, 1000);
> > >> + unsigned long j = usecs_to_jiffies(usecs);
> > >> +
> > >> + return min_t(unsigned long, MAX_JIFFY_OFFSET, j + 1);
> > >
> > > Or more concisely and review friendly:
> > >
> > > static inline unsigned long nsecs_to_jiffies_timeout(const u64 n)
> > > {
> > > return min_t(u64, MAX_JIFFY_OFFSET, nsecs_to_jiffies64(n) + 1);
> > > }
> >
> > Yea. This looks much nicer. Seems generic enough it might be better
> > added next to nsec_to_jiffies64() in kernel/time/time.c or jiffies.h
> > rather then in a driver header.
> >
> > And clearly the header comment in nsec_to_jiffies() warning its only
> > for the scheduler and not for use for drivers (for exactly the reason
> > of this patch) are not obvious/memorable enough for me and Thomas
> > makes me wonder if we should change its name to be more clear that its
> > a sched only function.
>
> This bug here isn't about nsect_to_jiffies vs the 64 bit variant, but
> about the +1 that we need to not have a short sleep. In i915 we have a
> bunch of jiffies_timeout functions which do just the +1 compared to the
> versions in time.c because we screwed this up too often.
>
> Iirc I did float an rfc to move these to time.c once but it resulted in
> some bikeshed fest (no, I'm not going to audit every single user of
> existing _to_jiffies functions). If there's interest I could try again,
> the i915 versions are in drivers/gpu/drm/i915/i915_drv.h.
There was at least this attempt:
https://lkml.org/lkml/2013/5/10/187
--Imre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
WARNING: multiple messages have this Message-ID (diff)
From: Imre Deak <imre.deak@intel.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: John Stultz <john.stultz@linaro.org>,
Daniel Vetter <daniel.vetter@ffwll.ch>,
Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
LKML <linux-kernel@vger.kernel.org>,
Daniel Vetter <daniel.vetter@intel.com>,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [Intel-gfx] [PATCH] drm/i915: compute wait_ioctl timeout correctly
Date: Wed, 03 Dec 2014 12:28:14 +0200 [thread overview]
Message-ID: <1417602494.2642.0.camel@intelbox> (raw)
In-Reply-To: <20141203092216.GZ32117@phenom.ffwll.local>
On Wed, 2014-12-03 at 10:22 +0100, Daniel Vetter wrote:
> On Tue, Dec 02, 2014 at 08:54:13AM -0800, John Stultz wrote:
> > On Tue, Dec 2, 2014 at 8:35 AM, Chris Wilson <chris@chris-wilson.co.uk> wrote:
> > > On Tue, Dec 02, 2014 at 04:36:22PM +0100, Daniel Vetter wrote:
> > >> +static inline unsigned long nsecs_to_jiffies_timeout(const u64 m)
> > >> +{
> > >> + u64 usecs = div_u64(m + 999, 1000);
> > >> + unsigned long j = usecs_to_jiffies(usecs);
> > >> +
> > >> + return min_t(unsigned long, MAX_JIFFY_OFFSET, j + 1);
> > >
> > > Or more concisely and review friendly:
> > >
> > > static inline unsigned long nsecs_to_jiffies_timeout(const u64 n)
> > > {
> > > return min_t(u64, MAX_JIFFY_OFFSET, nsecs_to_jiffies64(n) + 1);
> > > }
> >
> > Yea. This looks much nicer. Seems generic enough it might be better
> > added next to nsec_to_jiffies64() in kernel/time/time.c or jiffies.h
> > rather then in a driver header.
> >
> > And clearly the header comment in nsec_to_jiffies() warning its only
> > for the scheduler and not for use for drivers (for exactly the reason
> > of this patch) are not obvious/memorable enough for me and Thomas
> > makes me wonder if we should change its name to be more clear that its
> > a sched only function.
>
> This bug here isn't about nsect_to_jiffies vs the 64 bit variant, but
> about the +1 that we need to not have a short sleep. In i915 we have a
> bunch of jiffies_timeout functions which do just the +1 compared to the
> versions in time.c because we screwed this up too often.
>
> Iirc I did float an rfc to move these to time.c once but it resulted in
> some bikeshed fest (no, I'm not going to audit every single user of
> existing _to_jiffies functions). If there's interest I could try again,
> the i915 versions are in drivers/gpu/drm/i915/i915_drv.h.
There was at least this attempt:
https://lkml.org/lkml/2013/5/10/187
--Imre
next prev parent reply other threads:[~2014-12-03 10:28 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
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 [this message]
2014-12-03 10:28 ` 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=1417602494.2642.0.camel@intelbox \
--to=imre.deak@intel.com \
--cc=daniel.vetter@ffwll.ch \
--cc=daniel.vetter@intel.com \
--cc=daniel@ffwll.ch \
--cc=intel-gfx@lists.freedesktop.org \
--cc=john.stultz@linaro.org \
--cc=linux-kernel@vger.kernel.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.