From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Anholt Subject: Re: [PATCH v2] drm/vc4: Add a debugfs entry to disable/enable the load tracker Date: Mon, 03 Dec 2018 07:54:39 -0800 Message-ID: <87h8fufvwg.fsf@anholt.net> References: <20181130161104.16352-1-paul.kocialkowski@bootlin.com> <87r2f2patf.fsf@anholt.net> <20181202081440.0ec235c4@bbrezillon> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Return-path: In-Reply-To: <20181202081440.0ec235c4@bbrezillon> Sender: linux-kernel-owner@vger.kernel.org To: Boris Brezillon Cc: Paul Kocialkowski , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, David Airlie , Maxime Ripard , Thomas Petazzoni List-Id: dri-devel@lists.freedesktop.org --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Boris Brezillon writes: > On Fri, 30 Nov 2018 12:30:52 -0800 > Eric Anholt wrote: > >> Paul Kocialkowski writes: >>=20 >> > In order to test whether the load tracker is working as expected, we >> > need the ability to compare the commit result with the underrun >> > indication. With the load tracker always enabled, commits that are >> > expected to trigger an underrun are always rejected, so userspace >> > cannot get the actual underrun indication from the hardware. >> > >> > Add a debugfs entry to disable/enable the load tracker, so that a DRM >> > commit expected to trigger an underrun can go through with the load >> > tracker disabled. The underrun indication is then available to >> > userspace and can be checked against the commit result with the load >> > tracker enabled. >> > >> > Signed-off-by: Paul Kocialkowski =20=20 >>=20 >> Given that the load tracker is going to be conservative and say things >> will underrun even when they might not in practice, will this actually >> be useful for automated testing? Or is the intent to make it easier to >> tune the load tracker by disabling it so that you can experiment freely? > > Yes, that's one goal, though I'm not sure IGT is supposed to contain > such debugging tools. But the main benefit is being able to track > regressions in the load tracking algo that makes it more (too?) > conservative. I think people won't like this sort of regressions. The > idea would be to settle on an acceptable load tracking algo (maybe > after refining the proposed one), record the results (both good and too > conservative predictions) and use that as a reference for the IGT > test.=20=20 Yeah, I think I'm sold on it at this point -- having a tool that isn't an automated regression test, but an automated thing that can help a developer see how accurate the estimate is, would be useful and is worth a bit of kernel code to support. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE/JuuFDWp9/ZkuCBXtdYpNtH8nugFAlwFUb8ACgkQtdYpNtH8 nujBbA//X9Cj3ddTo7qwTzKJCthzrOC6ysbnyT/nXZnbUi4sO39gW5NxLhc7485k UYv3frUkXkMI+y9TvvnSaamBlqOTvXVZXiWLiVQyF4vgramlugwxeiJKZv09DZQe E+T5/zQd0WS7rCeqb2dcjkAjZTWrWTjAY7sMG0b0IXYhmw2lniDp9mbS3cyFrERp qFWf3Sdt8dmhlrqjzaj4Nf7P2fEATSxq/Ujv0WcSZu2AXX1fgNDzD2CMeT0xmyIm yqR1JWjw7hlwcSLmfjcsyJPjuq3v0uqP4a+Hs8MARNOZT7di6DBwughSd3reRvL7 cShlGwpPmZVgcCeYkXcTsp2k+P72+l+hw0VIiIY8CkDx69/Qo2O6TqxwDT89ffwy ivmT4dkNoQ+ls6HoUHwtOSC2Qng8UHj1vhX2iQtYqZQkAssWU1p1l5ySKuCHCDhY qkY45d/2Q1jtPopXTAKMLA8fqQWS/hcpZy7gWagfMBKGqG2wIuzMVNV0S1b0/cn5 GcIuylcqYlb9wM/vt/vkaasLmNZVDIoXgxV3mBc2JObcKPATdbYSGHtIeuxwk0BV m+GXVlgEvpCoDIdWRgSatIb4lCgxgUXCjqkmq7ZOHRPdW3COlKk4gfueJbyWqdh+ dICj5cO/CtizgNMYk6bYQu8Z+zI98GD2EnEbZthk9aq8KpnBrzo= =kQ/F -----END PGP SIGNATURE----- --=-=-=--