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@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
