[Intel-gfx] [PATCH] drm/i915: Use usleep_range() in wait_for()

[Ville Syrjälä]

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 at linux.intel.com wrote:
> > From: Ville Syrjälä <ville.syrjala at 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 at virtuousgeek.org>
> > Signed-off-by: Ville Syrjälä <ville.syrjala at linux.intel.com>
> 
> Reviewed-by: Chris Wilson <chris at 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