linux-kernel - Re: [PATCH] drm/panfrost: 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]

Message-ID: <38c4dc94-0613-33f9-e4e4-e42d451aed9b@arm.com>
Date:   Fri, 22 Jan 2021 10:00:44 +0000
From:   Lukasz Luba <lukasz.luba@....com>
To:     Steven Price <steven.price@....com>
Cc:     linux-kernel@...r.kernel.org, airlied@...ux.ie, daniel@...ll.ch,
        robh@...nel.org, tomeu.vizoso@...labora.com,
        alyssa.rosenzweig@...labora.com, dri-devel@...ts.freedesktop.org,
        daniel.lezcano@...aro.org
Subject: Re: [PATCH] drm/panfrost: Add governor data with pre-defined
 thresholds



On 1/22/21 8:21 AM, Steven Price wrote:
> On 21/01/2021 17:04, Lukasz Luba wrote:
>> The simple_ondemand devfreq governor uses two thresholds to decide about
>> the frequency change: upthreshold, downdifferential. These two tunable
>> change the behavior of the governor decision, e.g. how fast to increase
>> the frequency or how rapidly limit the frequency. This patch adds needed
>> governor data with thresholds values gathered experimentally in different
>> workloads.
>>
>> Signed-off-by: Lukasz Luba <lukasz.luba@....com>
>> ---
>> Hi all,
>>
>> This patch aims to improve the panfrost performance in various workloads,
>> (benchmarks, games). The simple_ondemand devfreq governor supports
>> tunables to tweak the behaviour of the internal algorithm. The default
>> values for these two thresholds (90 and 5) do not work well with 
>> panfrost.
>> These new settings should provide good performance, short latency for
>> rising the frequency due to rapid workload change and decent freq slow
>> down when the load is decaying. Based on frequency change statistics,
>> gathered during experiments, all frequencies are used, depending on
>> the load. This provides some power savings (statistically). The highest
>> frequency is also used when needed.
>>
>> Example glmark2 results:
>> 1. freq fixed to max: 153
>> 2. these new thresholds values (w/ patch): 151
>> 3. default governor values (w/o patch): 114
> 
> It would be good to state which platform this is on as this obviously 
> can vary depending on the OPPs available.

Sorry about that. It was Rock Pi 4B and I have mesa 20.2.4.

> 
> Of course the real fix here would be to improve the utilisation of the 
> GPU[1] so we actually hit the 90% threshold more easily (AFAICT kbase 
> uses the default 90/5 thresholds), but this seems like a reasonable 
> change for now.

Agree, improving the scheduler would be the best option. I'll have a
look at that patch and why it got this 10% lower performance. Maybe
I would find something during testing.

> 
> Reviewed-by: Steven Price <steven.price@....com>

Thank you for the review. I guess this patch would go through drm tree?

Regards,
Lukasz

> 
> Thanks,
> 
> Steve
> 
> [1] When I get some time I need to rework the "queue jobs on the 
> hardware"[2] patch I posted ages ago. Last time it actually caused a 
> performance regression though...
> 
> [2] https://lore.kernel.org/r/20190816093107.30518-2-steven.price%40arm.com
>