From mboxrd@z Thu Jan 1 00:00:00 1970 From: Francisco Jerez Subject: Re: [PATCH] drm/i915: Do not use iowait while waiting for the GPU Date: Sat, 28 Jul 2018 13:18:50 -0700 Message-ID: <87tvojf711.fsf@riseup.net> References: <20180727184312.29937-1-chris@chris-wilson.co.uk> <87pnz8gcmr.fsf@riseup.net> <153278776733.24377.4575869668307623950@skylake-alporthouse-com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1680273793==" Return-path: Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129]) by gabe.freedesktop.org (Postfix) with ESMTPS id AB0716E232 for ; Sat, 28 Jul 2018 20:35:46 +0000 (UTC) In-Reply-To: <153278776733.24377.4575869668307623950@skylake-alporthouse-com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" To: Chris Wilson , intel-gfx@lists.freedesktop.org Cc: Eero Tamminen List-Id: intel-gfx@lists.freedesktop.org --===============1680273793== Content-Type: multipart/signed; boundary="==-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" --==-=-= Content-Type: multipart/mixed; boundary="=-=-=" --=-=-= Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Chris Wilson writes: > Quoting Francisco Jerez (2018-07-28 06:20:12) >> Chris Wilson writes: >>=20 >> > A recent trend for cpufreq is to boost the CPU frequencies for >> > iowaiters, in particularly to benefit high frequency I/O. We do the sa= me >> > 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 bei= ng >> > reduced. Thus declaring iowait negatively impacts on GPU throughput. >> > >> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=3D107410 >> > References: 52ccc4314293 ("cpufreq: intel_pstate: HWP boost performanc= e on IO wakeup") >>=20 >> This patch causes up to ~13% performance regressions (with significance >> 5%) on several latency-sensitive tests on my BXT: >>=20 >> jxrendermark/rendering-test=3DLinear Gradient Blend/rendering-size=3D12= 8x128: XXX =C2=B135.69% x53 -> XXX =C2=B132.57% x61 d=3D-13.52% =C2=B13= 1.88% p=3D2.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 Stdd= ev > x 100 16109.095 16211.579 16152.497 16154.87 19.2707= 49 > + 100 16116.47 16274.973 16152.365 16156.954 25.3043= 98 > 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 --=-=-=-- --==-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEAREIAB0WIQST8OekYz69PM20/4aDmTidfVK/WwUCW1zPqgAKCRCDmTidfVK/ W1nxAP49NeCP0oxnGBLJEBMjdxYUSLIaO/aBrSDUyI4ETKqLmQD/bzEz/qE8j1w4 rtm2uLxJcdjFVY4KcNEsYtcVkYh8CP4= =SGiT -----END PGP SIGNATURE----- --==-=-=-- --===============1680273793== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KSW50ZWwtZ2Z4 IG1haWxpbmcgbGlzdApJbnRlbC1nZnhAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vaW50ZWwtZ2Z4Cg== --===============1680273793==--