From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Anholt Subject: Re: [PATCH] drm/etnaviv: bring back progress check in job timeout handler Date: Thu, 28 Jun 2018 10:35:02 -0700 Message-ID: <87r2kqx1a1.fsf@anholt.net> References: <20180627143427.25862-1-l.stach@pengutronix.de> <87k1qk2lbo.fsf@anholt.net> <1530175228.22468.41.camel@pengutronix.de> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0649645238==" Return-path: In-Reply-To: <1530175228.22468.41.camel@pengutronix.de> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Lucas Stach , Russell King Cc: dri-devel@lists.freedesktop.org, etnaviv@lists.freedesktop.org, kernel@pengutronix.de, patchwork-lst@pengutronix.de List-Id: dri-devel@lists.freedesktop.org --===============0649645238== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Lucas Stach writes: > Am Mittwoch, den 27.06.2018, 10:25 -0700 schrieb Eric Anholt: >> > Lucas Stach writes: >>=20 >> > When the hangcheck handler was replaced by the DRM scheduler timeout >> > handling we dropped the forward progress check, as this might allow >> > clients to hog the GPU for a long time with a big job. >> >=20 >> > It turns out that even reasonably well behaved clients like the >> > Armada Xorg driver occasionally trip over the 500ms timeout. Bring >> > back the forward progress check to get rid of the userspace regression. >> >=20 >> > We would still like to fix userspace to submit smaller batches >> > if possible, but that is for another day. >> >=20 >> > Fixes: 6d7a20c07760 (drm/etnaviv: replace hangcheck with scheduler tim= eout) >> > Signed-off-by: Lucas Stach >>=20 >> I was just wondering if there was a way to do this with the scheduler (I >> had a similar issue with GTF-GLES2.gtf.GL.acos.acos_float_vert_xvary), >> and this looks correct. > > What are you thinking about? A forward progress check at sub-fence > granularity is always going to be GPU specific. The only thing that > could be shunted to the scheduler is rearming of the timer. We could do > this by changing the return type of timedout_job to something that > allows us to indicate a false-positive to the scheduler. That sounds like a nice future improvement. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE/JuuFDWp9/ZkuCBXtdYpNtH8nugFAls1HEYACgkQtdYpNtH8 nujrQg//fKug7RaRGDzNq1acUdtrlJHDZCo/dHujyJV+x3qp9+b+oIl4g/R+J7VI mGcl8SW8p19WIOBFTLSDXIY0m6TgpIEBx97BluxDqtfoVC1Z3Ggma0Ena8K3NfSS j6CTbGSMG33Ev0ZXXFf4VHMR67iejyzlaVxJIycZ4peNwe42QlNWpT3aI8ARsFQA 3+ih2hPFnihlvON5ZaZL2FhoTh2slM1FiyOcFFP6TxLTGGcR1w3gz9s9GMSXyXdg ZOLEzfhSEbrFTA4Anlsp3PDpbRxKzP8wi3O1qFsMM3uDYlhYTCSenSe1veJlAhVj XMsJFg4G6k6pd1TDKJxfo9kIc2YcWP8dCVWngRAROs1o5pDeCbhH5GHBsoj7t/E9 xXdG8GY+g0rhg1B/uAWwJDFZ8rukx4QEXVFgjPrS+0/h3wVZuFxmR6jGJ74U6NVq xgfw/5ygCya69Vuj4s6sB9KHWqf13FZw4BoRdmJAHaVdL1rIR1j8yNc68ozyByiS Jr4dkkYC5d229UX0oXCNDOjiyVbjTlUT528uHOUMkDN+ELfvrBaR8hyLOhG98dJt hOfkLxunyR1ATnVH0V8AiKkxr/DlpEGI0fDG40ilVOZ5mEH4RLjdIZxYQWPHAa28 lGTy6gMHBOEIs2eeeZ4hW/hXRM+GjEX4v/Y/XSjHyWyV3yqvCQY= =CQAk -----END PGP SIGNATURE----- --=-=-=-- --===============0649645238== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCg== --===============0649645238==--