[Intel-gfx] [PATCH] drm/i915: Do not use iowait while waiting for the GPU

Francisco Jerez currojerez at riseup.net
Sat Jul 28 20:18:50 UTC 2018


Chris Wilson <chris at chris-wilson.co.uk> writes:

> Quoting Francisco Jerez (2018-07-28 06:20:12)
>> Chris Wilson <chris at chris-wilson.co.uk> writes:
>> 
>> > A recent trend for cpufreq is to boost the CPU frequencies for
>> > iowaiters, in particularly to benefit high frequency I/O. We do the same
>> > and boost the GPU clocks to try and minimise time spent waiting for the
>> > GPU. However, as the igfx and CPU share the same TDP, boosting the CPU
>> > frequency will result in the GPU being throttled and its frequency being
>> > reduced. Thus declaring iowait negatively impacts on GPU throughput.
>> >
>> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107410
>> > References: 52ccc4314293 ("cpufreq: intel_pstate: HWP boost performance on IO wakeup")
>> 
>> This patch causes up to ~13% performance regressions (with significance
>> 5%) on several latency-sensitive tests on my BXT:
>> 
>>  jxrendermark/rendering-test=Linear Gradient Blend/rendering-size=128x128:     XXX ±35.69% x53 -> XXX ±32.57% x61 d=-13.52% ±31.88% p=2.58%
>

The jxrendermark Linear Gradient Blend test-case had probably the
smallest effect size of all the regressions I noticed...  Can you take a
look at any of the other ones instead?

> Curious, as this is just a bunch of composites and as with the others,
> should never be latency sensitive (at least under bare X11).

They are largely latency-sensitive due to the poor pipelining they seem
to achieve between their GPU rendering work and the X11 thread.

> Fwiw, I double checked this result:
>
> Broxton J3455, jxrend -num $(for i in $(seq 1 100); do echo 12 128; done)
> x noio-1.txt
> + io-1.txt
> +------------------------------------------------------------------------+
> |                 +                                                      |
> |                 +                                                      |
> |                 *                                                      |
> |                +*x                                                     |
> |              + +***+                                                   |
> |              + +***++                                                  |
> |              + ****+*   +                                              |
> |             ++x******  x+   x                                          |
> |       xx    **x*******+x* xx*                                          |
> |   + + xx*xx+***********x**x***x x+                                     |
> |x x+** x**x****************x***x***+  x + x x                    ++    +|
> |           |_______MA_______|                                           |
> |          |________MA__________|                                        |
> +------------------------------------------------------------------------+
>     N           Min           Max        Median           Avg        Stddev
> x 100     16109.095     16211.579     16152.497      16154.87     19.270749
> + 100      16116.47     16274.973     16152.365     16156.954     25.304398
> No difference proven at 95.0% confidence
>
> Your variance is much, much higher, are you still using the original
> jxrendermark that doesn't wait for rendering completion?

I bet, but the other regressing benchmarks shouldn't be affected.

> -Chris
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/intel-gfx/attachments/20180728/ea011414/attachment.sig>


More information about the Intel-gfx mailing list