[Intel-gfx] [PATCH v3] drm/i915: Optimistically spin for the request completion

[Daniel Vetter]

On Thu, Mar 12, 2015 at 05:32:26PM +0000, Tvrtko Ursulin wrote:
> 
> On 03/12/2015 04:50 PM, Chris Wilson wrote:
> >On Thu, Mar 12, 2015 at 04:41:10PM +0000, Tvrtko Ursulin wrote:
> >>Yes I didn't mean that - but to have a boolean spinning-wait=on/off.
> >>Maybe default to "on" on HZ=1000 with preemption, or the opposite,
> >>something like that.
> >
> >I don't see the point in having the complication, until someone
> >complains. In my defense, I will point to the optimistic mutex spinning
> >equally having no configurable option. And since the idea is that you
> >only hit this if you are abusing i915 (e.g. benchmarking, or you have a
> >readback on the critical patch, or if we haven't implemented
> >semaphores), I would rather fix those scenarios as they arrive rather
> >than giving the user an option to break.
> 
> I simply pointed out a theoretical potential to burn more CPU on servers. If
> you know that is unlikely or only theoretical that's fine by me.
> 
> But I'll say I was more convinced before you mentioned "until someone
> complains" and "option to break". :)

Server workloads on intel machines are currently transcode stuff (and
there's more room in libva for better parallelism than this) and ocl
(which tends to go with the busy-loops for synchronization model anyway).

Also we'll stop spinning the second someone else wants the cpu, so there's
really just secondary effects of the scheduler due to fewer iowait credits
and more timeslices used up. I'll go with Chris and will start to care
when someone complains with real benchmark numbers attached ;-)

Ofc we still want broader numbers for the benchmakr benefits for this one
first.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch