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