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

[Tvrtko Ursulin]

On 03/12/2015 01:18 PM, Chris Wilson wrote:
> On Thu, Mar 12, 2015 at 01:14:30PM +0000, Tvrtko Ursulin wrote:
>> On 03/12/2015 11:11 AM, Chris Wilson wrote:
>>> This provides a nice boost to mesa in swap bound scenarios (as mesa
>>> throttles itself to the previous frame and given the scenario that will
>>> complete shortly). It will also provide a good boost to systems running
>>> with semaphores disabled and so frequently waiting on the GPU as it
>>> switches rings. In the most favourable of microbenchmarks, this can
>>> increase performance by around 15% - though in practice improvements
>>> will be marginal and rarely noticeable.
>>>
>>> v2: Account for user timeouts
>>> v3: Limit the spinning to a single jiffie (~1us) at most. On an
>>> otherwise idle system, there is no scheduler contention and so without a
>>> limit we would spin until the GPU is ready.
>>
>> Isn't one jiffie 1-10ms typically?
>
> 1ms. I was just thinking of doing USECS_PER_SEC / HZ, then realised that
> was a jiffie, hence the confusion. At any rate, it is still the minimum
> we can trivially wait for (without an expensive hrtimer).

Unless I lost track with the times, that's CONFIG_HZ right?

I don't know what server distributions do, but this Ubuntu LTS I am 
running has HZ=250 which means 4ms.

That would mean on a system where throughput is more important than 
latency, you lose most throughput by spinning the longest. In theory at 
least, no?

So perhaps which should be a tunable? Optionally auto-select the initial 
state based on HZ.

Regards,

Tvrtko