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. Oh, that is bad. /o\ -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
