Messages in this thread | | | Subject | Re: [PATCH] drm/panfrost: Add governor data with pre-defined thresholds | From | Lukasz Luba <> | Date | Fri, 22 Jan 2021 10:00:44 +0000 |
| |
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@arm.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@arm.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 >
| |