From: skannan@codeaurora.org
To: myungjoo.ham@samsung.com
Cc: Kyungmin Park <kyungmin.park@samsung.com>,
Chanwoo Choi <cw00.choi@samsung.com>,
Rob Herring <robh+dt@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
georgi.djakov@linaro.org, vincent.guittot@linaro.org,
daidavid1@codeaurora.org, bjorn.andersson@linaro.org,
linux-pm@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 1/2] PM / devfreq: Generic CPU frequency to device frequency mapping governor
Date: Mon, 06 Aug 2018 22:49:48 -0700 [thread overview]
Message-ID: <35ff3e303f5de9980979b49c89f9a687@codeaurora.org> (raw)
In-Reply-To: <45c77ee02536e237c054399cad4c7669@codeaurora.org>
On 2018-08-02 14:00, skannan@codeaurora.org wrote:
> On 2018-08-02 02:56, MyungJoo Ham wrote:
>>> Many CPU architectures have caches that can scale independent of the
>>> CPUs.
>>> Frequency scaling of the caches is necessary to make sure the cache
>>> is not
>>> a performance bottleneck that leads to poor performance and power.
>>> The same
>>> idea applies for RAM/DDR.
>>>
>>> To achieve this, this patch adds a generic devfreq governor that
>>> takes the
>>> current frequency of each CPU frequency domain and then adjusts the
>>> frequency of the cache (or any devfreq device) based on the frequency
>>> of
>>> the CPUs. It listens to CPU frequency transition notifiers to keep
>>> itself
>>> up to date on the current CPU frequency.
>>>
>>> To decide the frequency of the device, the governor does one of the
>>> following:
>>
>> This exactly has the same purpose with "passive" governor except for
>> the
>> single part: passive governor depends on another devfreq driver, not
>> cpufreq driver.
>>
>> If both governors have many features in common, can you merge them
>> into one?
>> Passive governor also has "get_target_freq", which allows driver
>> authors
>> to define the mapping.
>
> Thanks for the review and pointing me to the passive governor. I agree
> that at a high level they are both doing the same. I can certainly
> stuff this CPU freq to dev freq mapping into passive governor, but I
> think it'll just make one huge set of code that's harder to understand
> and maintain because it trying to do different things under the hood.
>
> There are also a bunch of complexities and optimizations that come
> with the cpufreq-map governor that don't fit with the passive
> governor.
>
> 1. It's not one CPU who's frequency we have to listen to. There are
> multiple CPUs/policies we have to aggregate across.
> 2. We have to deal with big vs little having different needs/mappings.
> 3. Since it's always just CPUfreq, I can optimize the handling in the
> transition notifiers. If I have 4 different devices that are scaled
> based on CPU freq, I still use only 1 transition notifier. It becomes
> a bit harder to do with the passive governor.
> 4. It requires that the device explicitly support the passive governor
> and pick a mapping function. With cpufreq-map governor, the device
> drivers don't need to make any changes. Whoever is making a
> device/board can choose what devices to scale up base on CPU freq
> based on their board and their needs. Even an end user can say, scale
> the GPU based on my CPU based on interpolation if they choose to.
> 5. If a device has some other use for the private data, it can't work
> with passive governor, but can work with cpufreq-map governor.
> 6. I also want to improve cpufreq-map governor to handle hotplug
> correctly in later patches (needs more discussion) and that'll add
> more complexity.
>
> I think for these reasons we shouldn't combine these two governors.
> Let me know what you think.
Friendly reminder.
Thanks,
Saravana
next prev parent reply other threads:[~2018-08-07 5:49 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-02 0:57 [PATCH v3 1/2] PM / devfreq: Generic CPU frequency to device frequency mapping governor Saravana Kannan
[not found] ` <CGME20180802005756epcas4p465a12f42a0e36f0af6fd276a3a56957f@epcms1p3>
2018-08-02 9:56 ` MyungJoo Ham
2018-08-02 21:00 ` skannan
2018-08-07 5:49 ` skannan [this message]
2018-09-10 18:45 ` Sibi Sankar
2018-08-07 16:41 ` Rob Herring
2018-08-07 19:37 ` skannan
2018-08-08 8:47 ` Sudeep Holla
2018-08-08 21:18 ` skannan
2018-08-09 9:43 ` Sudeep Holla
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=35ff3e303f5de9980979b49c89f9a687@codeaurora.org \
--to=skannan@codeaurora.org \
--cc=bjorn.andersson@linaro.org \
--cc=cw00.choi@samsung.com \
--cc=daidavid1@codeaurora.org \
--cc=devicetree@vger.kernel.org \
--cc=georgi.djakov@linaro.org \
--cc=kyungmin.park@samsung.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=myungjoo.ham@samsung.com \
--cc=robh+dt@kernel.org \
--cc=vincent.guittot@linaro.org \
/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).