linux-kernel - Re: [PATCH v2] drm/vc4: Add a debugfs entry to disable/enable the load tracker

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Mon, 03 Dec 2018 07:54:39 -0800
From:   Eric Anholt <eric@...olt.net>
To:     Boris Brezillon <boris.brezillon@...tlin.com>
Cc:     Paul Kocialkowski <paul.kocialkowski@...tlin.com>,
        dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org,
        David Airlie <airlied@...ux.ie>,
        Maxime Ripard <maxime.ripard@...tlin.com>,
        Thomas Petazzoni <thomas.petazzoni@...tlin.com>
Subject: Re: [PATCH v2] drm/vc4: Add a debugfs entry to disable/enable the load tracker

Boris Brezillon <boris.brezillon@...tlin.com> writes:

> On Fri, 30 Nov 2018 12:30:52 -0800
> Eric Anholt <eric@...olt.net> wrote:
>
>> Paul Kocialkowski <paul.kocialkowski@...tlin.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@...tlin.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.  

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.

Download attachment "signature.asc" of type "application/pgp-signature" (833 bytes)