linux-kernel - Re: [PATCH] drm/lima: add governor data with pre-defined thresholds

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] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 27 Jan 2021 23:35:01 +0400
From:   Christian Hewitt <christianshewitt@...il.com>
To:     Lukasz Luba <lukasz.luba@....com>
Cc:     Qiang Yu <yuq825@...il.com>, David Airlie <airlied@...ux.ie>,
        Daniel Vetter <daniel@...ll.ch>,
        dri-devel@...ts.freedesktop.org, lima@...ts.freedesktop.org,
        linux-kernel@...r.kernel.org, Steven Price <steven.price@....com>
Subject: Re: [PATCH] drm/lima: add governor data with pre-defined thresholds


> On 27 Jan 2021, at 3:11 pm, Lukasz Luba <lukasz.luba@....com> wrote:
> 
> On 1/27/21 10:24 AM, Lukasz Luba wrote:
>> Hi Christian,
>> On 1/25/21 8:18 AM, Christian Hewitt wrote:
>>> This patch adapts the panfrost pre-defined thresholds change [0] to the
>>> lima driver to improve real-world performance. The upthreshold value has
>>> been set to ramp GPU frequency to max freq faster (compared to panfrost)
>>> to compensate for the lower overall performance of utgard devices.
>>> 
>>> [0] https://patchwork.kernel.org/project/dri-devel/patch/20210121170445.19761-1-lukasz.luba@arm.com/ 
>>> 
>>> Signed-off-by: Christian Hewitt <christianshewitt@...il.com>
>>> ---
>>> I have been using Kodi as my test application. If you scroll in library
>>> views with hundreds of list items and the panfrost values the slow GPU
>>> ramp up is quite noticeable and the GUI feels sluggish. As everything
>>> lima runs on is inherently slower than panfrost using devices I believe
>>> it's better to ramp up to max freq quicker.
>> It's quite low value for the upthreshold, but I believe you have
>> experimented and observed that a bit higher (30, 40?) don't work well.
>> I don't know the Kodi system, though.
>> You can check if the other frequencies are also used in statistics for
>> devfreq device:
>> cat /sys/class/devfreq/<your_gpu>/trans_stats
>> If they are also used, then it OK (better than stuck at min freq).
> 
> I've just realized that your board might suffer a another issue.
> Please apply this patch [1] and run your experiments with upthresholds.
> 
> [1] https://lore.kernel.org/lkml/20210127105121.20345-1-lukasz.luba@arm.com/

I’ve included the patch and with unscientific testing it feels snappier with a larger value than
before. I did revert back to 45 first, but again this feels sluggish when navigating around the
Kodi GUI. My main test is to enter ‘Movies’ in Kodi then start scrolling in a long list. When
the GPU ramps up quickly the experience is snappy, but when it ramps more conservatively
scrolling feels like it stutters, then (once you hit max freq) it becomes fluid.

WP2:~ # cat /sys/class/devfreq/d00c0000.gpu/trans_stat 
     From  :   To
           : 125000000 250000000 285714285 400000000 500000000 666666666 744000000   time(ms)
* 125000000:         0         0         0         0         0         0       264     52720
  250000000:         9         0         0         0         0         0        36      3404
  285714285:         9         3         0         0         0         0        32      2628
  400000000:        18        20        13         0         0         0       191     21140
  500000000:        12        12         8        63         0         0        31     10068
  666666666:       179         5        16       133        66         0        24     29360
  744000000:        37         5         7        46        60       423         0     46016

I’ll send v2 with the value set to 30.

Christian