All of lore.kernel.org
 help / color / mirror / Atom feed
From: Francisco Jerez <currojerez@riseup.net>
To: Chris Wilson <chris@chris-wilson.co.uk>, intel-gfx@lists.freedesktop.org
Cc: Eero Tamminen <eero.t.tamminen@intel.com>
Subject: Re: [PATCH] drm/i915: Do not use iowait while waiting for the GPU
Date: Sat, 28 Jul 2018 13:18:50 -0700	[thread overview]
Message-ID: <87tvojf711.fsf@riseup.net> (raw)
In-Reply-To: <153278776733.24377.4575869668307623950@skylake-alporthouse-com>


[-- Attachment #1.1.1: Type: text/plain, Size: 3352 bytes --]

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

> Quoting Francisco Jerez (2018-07-28 06:20:12)
>> Chris Wilson <chris@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

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

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

  reply	other threads:[~2018-07-28 20:35 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-27 18:43 [PATCH] drm/i915: Do not use iowait while waiting for the GPU Chris Wilson
2018-07-27 18:58 ` Chris Wilson
2018-07-27 19:35 ` ✗ Fi.CI.CHECKPATCH: warning for " Patchwork
2018-07-27 19:55 ` [PATCH] " Chris Wilson
2018-07-27 19:56 ` ✓ Fi.CI.BAT: success for " Patchwork
2018-07-27 20:51 ` ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Do not use iowait while waiting for the GPU (rev2) Patchwork
2018-07-27 21:14 ` ✓ Fi.CI.BAT: success " Patchwork
2018-07-28  5:20 ` [PATCH] drm/i915: Do not use iowait while waiting for the GPU Francisco Jerez
2018-07-28 14:22   ` Chris Wilson
2018-07-28 20:18     ` Francisco Jerez [this message]
2018-07-28 20:58       ` Chris Wilson
2018-07-29 19:29         ` Francisco Jerez
2018-07-30 12:56           ` Chris Wilson
2018-07-30 18:55             ` Francisco Jerez
2018-07-28 16:27   ` Chris Wilson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87tvojf711.fsf@riseup.net \
    --to=currojerez@riseup.net \
    --cc=chris@chris-wilson.co.uk \
    --cc=eero.t.tamminen@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.