From: Steven Price <steven.price@arm.com>
To: Lukasz Luba <lukasz.luba@arm.com>,
Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: linux-kernel@vger.kernel.org, airlied@linux.ie, daniel@ffwll.ch,
robh@kernel.org, tomeu.vizoso@collabora.com,
alyssa.rosenzweig@collabora.com, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH] drm/panfrost: Add governor data with pre-defined thresholds
Date: Fri, 22 Jan 2021 10:20:06 +0000 [thread overview]
Message-ID: <66a8f61a-3c4c-5f92-c175-f71c9dcfaf4a@arm.com> (raw)
In-Reply-To: <ec393a2c-2220-9ea8-db5c-7d651badc6b9@arm.com>
On 22/01/2021 10:11, Lukasz Luba wrote:
>
>
> On 1/21/21 5:15 PM, Daniel Lezcano wrote:
>> On 21/01/2021 18: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
>>>
>>> In future the devfreq framework would expose via sysfs these two
>>> tunables, so they can be adjusted by the middleware based on currently
>>> running workload (game, desktop, web browser, etc). These new values
>>> should be good enough, though.
>>>
>>> Regards,
>>> Lukasz Luba
>>>
>>> drivers/gpu/drm/panfrost/panfrost_devfreq.c | 10 +++++++++-
>>> drivers/gpu/drm/panfrost/panfrost_devfreq.h | 2 ++
>>> 2 files changed, 11 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
>>> b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
>>> index 56b3f5935703..7c5ffc81dce1 100644
>>> --- a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
>>> +++ b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
>>> @@ -130,8 +130,16 @@ int panfrost_devfreq_init(struct panfrost_device
>>> *pfdev)
>>> panfrost_devfreq_profile.initial_freq = cur_freq;
>>> dev_pm_opp_put(opp);
>>> + /*
>>> + * Setup default thresholds for the simple_ondemand governor.
>>> + * The values are chosen based on experiments.
>>> + */
>>> + pfdevfreq->gov_data.upthreshold = 45;
>>> + pfdevfreq->gov_data.downdifferential = 5;
>>> +
>>> devfreq = devm_devfreq_add_device(dev, &panfrost_devfreq_profile,
>>> - DEVFREQ_GOV_SIMPLE_ONDEMAND, NULL);
>>> + DEVFREQ_GOV_SIMPLE_ONDEMAND,
>>> + &pfdevfreq->gov_data);
>>> if (IS_ERR(devfreq)) {
>>> DRM_DEV_ERROR(dev, "Couldn't initialize GPU devfreq\n");
>>> ret = PTR_ERR(devfreq);
>>> diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.h
>>> b/drivers/gpu/drm/panfrost/panfrost_devfreq.h
>>> index db6ea48e21f9..1e2a4de941aa 100644
>>> --- a/drivers/gpu/drm/panfrost/panfrost_devfreq.h
>>> +++ b/drivers/gpu/drm/panfrost/panfrost_devfreq.h
>>> @@ -4,6 +4,7 @@
>>> #ifndef __PANFROST_DEVFREQ_H__
>>> #define __PANFROST_DEVFREQ_H__
>>> +#include <linux/devfreq.h>
>>> #include <linux/spinlock.h>
>>> #include <linux/ktime.h>
>>> @@ -17,6 +18,7 @@ struct panfrost_devfreq {
>>> struct devfreq *devfreq;
>>> struct opp_table *regulators_opp_table;
>>> struct thermal_cooling_device *cooling;
>>> + struct devfreq_simple_ondemand_data gov_data;
>>> bool opp_of_table_added;
>>> ktime_t busy_time;
>>
>> I think it is simpler to do:
>>
>> +static struct devfreq_simple_ondemand_data panfrost_ondemand_data = {
>> + .upthreshold = 45,
>> + .downdifferential = 5,
>> +};
>>
>> [ ... ]
>>
>> devfreq = devm_devfreq_add_device(dev, &panfrost_devfreq_profile,
>> - DEVFREQ_GOV_SIMPLE_ONDEMAND,
>> NULL);
>> + DEVFREQ_GOV_SIMPLE_ONDEMAND,
>> + &panfrost_ondemand_data);
>>
>>
>
> Yes, it's simpler. The driver would probably never have to serve two
> GPUs. I've tried to keep this thing inside the panfrost struct,
> forgetting about it.
The Juno platform with an FPGA attached is the only example I know of
where a system has multiple Mali GPUs - so it can happen, but it rare.
As it stands a static structure would work because the values are
constant - but Lukasz mentioned that they would be exported in sysfs in
the future, in which case they really should be part of the panfrost struct.
Ultimately having a (non-const) static struct like above would mean
wasting a few bytes on systems with Panfrost loaded but no Mali GPU.
Having it in struct panfrost means the cost is only for Mali. Admittedly
it's only a few bytes in this case and often Panfrost will be a module.
Steve
> Steven already reviewed the patch, so it can probably stay.
> I will keep it in mind. Thank you for the comments.
>
> Regards,
> Lukasz
next prev parent reply other threads:[~2021-01-22 10:27 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-21 17:04 [PATCH] drm/panfrost: Add governor data with pre-defined thresholds Lukasz Luba
2021-01-21 17:15 ` Daniel Lezcano
2021-01-22 10:11 ` Lukasz Luba
2021-01-22 10:20 ` Steven Price [this message]
2021-01-22 8:21 ` Steven Price
2021-01-22 10:00 ` Lukasz Luba
2021-01-22 10:24 ` Steven Price
2021-01-22 10:54 ` Lukasz Luba
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=66a8f61a-3c4c-5f92-c175-f71c9dcfaf4a@arm.com \
--to=steven.price@arm.com \
--cc=airlied@linux.ie \
--cc=alyssa.rosenzweig@collabora.com \
--cc=daniel.lezcano@linaro.org \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lukasz.luba@arm.com \
--cc=robh@kernel.org \
--cc=tomeu.vizoso@collabora.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;
as well as URLs for NNTP newsgroup(s).