public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/i915: Use usleep_range() in wait_for()
Date: Mon, 23 Mar 2015 11:39:12 +0200	[thread overview]
Message-ID: <20150323093912.GD17419@intel.com> (raw)
In-Reply-To: <20150320210951.GA16648@nuc-i3427.alporthouse.com>

On Fri, Mar 20, 2015 at 09:09:51PM +0000, Chris Wilson wrote:
> On Fri, Mar 20, 2015 at 09:28:08PM +0200, ville.syrjala@linux.intel.com wrote:
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > 
> > msleep() can sleep for way too long, so switch wait_for() to use
> > usleep_range() instead. Following a totally unscientific method
> > I just picked the range as W-2W.
> > 
> > This cuts the i915 init time on my BSW to almost half:
> > - initcall i915_init+0x0/0xa8 [i915] returned 0 after 419977 usecs
> > + initcall i915_init+0x0/0xa8 [i915] returned 0 after 238419 usecs
> > 
> > Note that I didn't perform any other benchmarks on this so far.
> > 
> > Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
> > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> 
> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
> 
> Hmm, I think we can improve further with a more variable sleep. The
> maximum we pass to wait_for() is usually plucked from somewhere in the
> spec (or is just a safety factor). Either way, it is a good guide as to
> how to actually sleep for - if say we try to only sample 1000 times up
> to the maximum:
> 
> if (do_sleep && drm_can_sleep()) {
> 	usleep_range((MS), 10*(MS));
> }
> 
> So whilst you have a situation where we clearly sleep too long between
> sampling (a register), it would be beneficial to start adding some debug
> infrastructure. Or even better if usleep_range already does it for us...

Yeah, it would be nice to have some more information about how long we
sleep typically in each case.

We could perhaps then even micro optimize the 'set knob -> poll for knob
to become active' pattern by doing a preemptive sleep between the set
and poll steps in the hopes that we don't have to check the condition
more than once. Not sure that would be worth the effort though.

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2015-03-23  9:39 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-20 19:28 [PATCH] drm/i915: Use usleep_range() in wait_for() ville.syrjala
2015-03-20 19:31 ` Jesse Barnes
2015-03-23  9:30   ` Daniel Vetter
2015-03-20 21:09 ` Chris Wilson
2015-03-23  9:39   ` Ville Syrjälä [this message]
2015-03-23  9:46     ` Daniel Vetter
2015-03-20 23:38 ` shuang.he

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=20150323093912.GD17419@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=chris@chris-wilson.co.uk \
    --cc=intel-gfx@lists.freedesktop.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox