[Intel-gfx] [PATCH] RFC drm/i915: Slaughter the thundering i915_wait_request herd

[Chris Wilson]

On Wed, Nov 04, 2015 at 06:19:33AM +0000, Gong, Zhipeng wrote:
> > From: Chris Wilson [mailto:chris at chris-wilson.co.uk]
> > On Tue, Nov 03, 2015 at 01:31:22PM +0000, Gong, Zhipeng wrote:
> > >
> > > > From: Chris Wilson [mailto:chris at chris-wilson.co.uk]
> > > >
> > > > Do you also have a relative perf statistics like op/s we can compare
> > > > to make sure we aren't just stalling the whole system?
> > > >
> > > Could you please provide the commands about how to check it?
> > 
> > I was presuming your workload has some measure of efficiency/throughput?
> > It is one thing to say we are using 10% less CPU (per second), but the task is
> > running 2x as long!
> We use execute time as a measurement, the patch affects the execution time 
> for our cases slightly.
> 
> Exec time(s)    |   w/o patch   |   w/patch
> -----------------------------------------------
> BDW async 1     |    65.00      |    65.25
> BDW async 5     |    68.50      |    66.42

That's reassuring.
 
> > 
> > > > How much cpu time is left in the i915_wait_request branch? i.e. how
> > > > close to the limit are we with chasing this path?
> > > Could you please provide the commands here either? :)
> > 
> > Check the perf callgraph.
> 
> Now the most of time is in io_schedule_timeout
> __i915_wait_request  
> |--64.04%-- io_schedule_timeout
> |--22.04%-- intel_engine_add_wakeup
> |--3.13%-- prepare_to_wait
> |--2.99%-- gen6_rps_boost
> |-...

No more busywaits, and most of the time is spent kicking the next
process or doing the insertion sort into the waiting rbtree.

What's the ratio now of __i915_wait_request to the next hot function?
And who are the chief callers of __i915_wait_request?
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre