Re: [PATCH v3] drm/i915: Optimistically spin for the request completion

[Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>]

On 03/12/2015 04:28 PM, Chris Wilson wrote:
> On Thu, Mar 12, 2015 at 03:18:01PM +0000, Tvrtko Ursulin wrote:
>> On 03/12/2015 01:18 PM, Chris Wilson wrote:
>>> 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?
>
> Only in theory, and only if you mean throughput of non-i915 workloads
> with preemption disabled.  Spinning here improves both latency and
> throughput for gfx clients. Using up the timeslice for the client may
> have secondary effects though - otherwise they would get iowait credits.

Yes, I meant CPU workloads. And low HZ and no preemption usually go 
together.

>> So perhaps which should be a tunable? Optionally auto-select the
>> initial state based on HZ.
>
> Spinning less than a jiffie requires hrtimers at which point you may as
> well just use the i915 interrupt (rather than setup a timer interrupt).

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.

Regards,

Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx