[Intel-gfx] [PATCH] drm/i915: Replace some more busy waits with normal ones

Chris Wilson chris at chris-wilson.co.uk
Thu Mar 24 13:31:09 UTC 2016


On Thu, Mar 24, 2016 at 01:16:40PM +0000, Chris Wilson wrote:
> On Thu, Mar 24, 2016 at 01:06:41PM +0000, Tvrtko Ursulin wrote:
> > 
> > On 24/03/16 12:27, Chris Wilson wrote:
> > >On Thu, Mar 24, 2016 at 11:37:07AM +0000, Tvrtko Ursulin wrote:
> > >>
> > >>On 23/03/16 16:40, Chris Wilson wrote:
> > >>>On Wed, Mar 23, 2016 at 04:24:48PM +0000, Tvrtko Ursulin wrote:
> > >>>>Biggest thing to make sure is that you don't add a lot of cycles to
> > >>>>the forcewake loops since for example fw_domains_get can be the
> > >>>>hottest i915 function on some benchmarks.
> > >>>>
> > >>>>(This area slightly annoys me anyway with redundant looping over
> > >>>>forcewake domains and we could also potentially optimize the ack
> > >>>>waiting by first requesting all we want, and then doing the waits.
> > >>>>That would be one additional loop, but if removed the other one,
> > >>>>code would stay at the same number of domain loops.)
> > >>>
> > >>>I hear you. I just end up weeping in the corner when I see fw_domain_get
> > >>>on the profile.
> > >>>
> > >>>We already do have a mitigation scheme to hold onto the forcewake for an
> > >>>extra jiffie every time. I don't like it, but without it fw_domains_get
> > >>>becomes a real hog.
> > >>
> > >>I am pretty sure I've seen some tests which somehow defeat the
> > >>jiffie delay and we end up re-acquiring every ms/jiffie. This is
> > >>something I wanted to get to the bottom of but did not get round to
> > >>yet. It was totally unexpected because the test is hammering on
> > >>everything.
> > >
> > >Absolutely sure it is not just the delay in acquiring the ack? And
> > >spinning on waiting for the thread_c0 doesn't come cheap? I've just
> > >written off fw_domain_get being high on the profiles simply due to that
> > >we have to spin so long (I'm jaded because on Sandybridge spinning for
> > >50us+ isn't uncommon iirc).
> > 
> > I am not sure, I just know I had a printk in the timer release and
> > it was firing every millisecond which completely perplexed me since
> > I was running gem_exec_nop/all at the time.
> 
> Well we don't need to arm the timer in both the get and put, do we Mika!
> 
> Mika, please send a fix so we only arm the timer when putting. And blame
> the reviewer.

Even worse, you copied my mistake! Darn.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre


More information about the Intel-gfx mailing list