public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Boris Brezillon <boris.brezillon@bootlin.com>
To: Eric Anholt <eric@anholt.net>
Cc: Paul Kocialkowski <paul.kocialkowski@bootlin.com>,
	dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
	David Airlie <airlied@linux.ie>,
	Maxime Ripard <maxime.ripard@bootlin.com>,
	Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Subject: Re: [PATCH v2] drm/vc4: Add a debugfs entry to disable/enable the load tracker
Date: Sun, 2 Dec 2018 08:14:40 +0100	[thread overview]
Message-ID: <20181202081440.0ec235c4@bbrezillon> (raw)
In-Reply-To: <87r2f2patf.fsf@anholt.net>

On Fri, 30 Nov 2018 12:30:52 -0800
Eric Anholt <eric@anholt.net> wrote:

> Paul Kocialkowski <paul.kocialkowski@bootlin.com> writes:
> 
> > 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 <paul.kocialkowski@bootlin.com>  
> 
> 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.  

  parent reply	other threads:[~2018-12-02  7:14 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-30 16:11 [PATCH v2] drm/vc4: Add a debugfs entry to disable/enable the load tracker Paul Kocialkowski
2018-11-30 18:57 ` Boris Brezillon
2018-12-01  9:59   ` Paul Kocialkowski
2018-11-30 20:30 ` Eric Anholt
2018-12-01  9:58   ` Paul Kocialkowski
2018-12-02  7:14   ` Boris Brezillon [this message]
2018-12-03 15:54     ` Eric Anholt

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=20181202081440.0ec235c4@bbrezillon \
    --to=boris.brezillon@bootlin.com \
    --cc=airlied@linux.ie \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=eric@anholt.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maxime.ripard@bootlin.com \
    --cc=paul.kocialkowski@bootlin.com \
    --cc=thomas.petazzoni@bootlin.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox