[lkml]   [2018]   [Aug]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] PM / devfreq: Generic cpufreq governor
On Tue, Jul 31, 2018 at 9:21 PM,  <> wrote:
> On 2018-07-31 01:00, Rafael J. Wysocki wrote:
>> On Mon, Jul 30, 2018 at 8:58 PM, <> wrote:
>>> On 2018-07-29 03:52, Rafael J. Wysocki wrote:
>>>> On Sat, Jul 28, 2018 at 5:56 AM, Saravana Kannan
>>>> <>
>>>> 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 can
>>>>> listen
>>>>> to the frequency transitions of each CPU frequency domain and then
>>>>> adjusts
>>>>> the frequency of the cache (or any devfreq device) based on the
>>>>> frequency
>>>>> of the CPUs.
>>>>> To decide the frequency of the device, the governor does one of the
>>>>> following:
>>>>> * Uses a CPU frequency to device frequency mapping table
>>>>> - Either one mapping table used for all CPU freq policies (typically
>>>>> used
>>>>> for system with homogeneous cores/clusters that have the same OPPs.
>>>>> - One mapping table per CPU freq policy (typically used for ASMP
>>>>> systems
>>>>> with heterogeneous CPUs with different OPPs)
>>>>> OR
>>>>> * Scales the device frequency in proportion to the CPU frequency. So,
>>>>> if
>>>>> the CPUs are running at their max frequency, the device runs at its
>>>>> max
>>>>> frequency. If the CPUs are running at their min frequency, the
>>>>> device
>>>>> runs at its min frequency. And interpolated for frequencies in
>>>>> between.
>>>> While not having looked at the details of the patch yet, I would
>>>> change the name of the feature to "Generic cpufreq transition
>>>> governor" to make it somewhat less ambiguous.
>>> In my opinion it makes it look MORE like this is a cpufreq governor. How
>>> about the following?
>>> PM / devfreq: Generic cpufreq to devfreq mapping governor
>>> Seem a lot more clear to me.
>> Well, it's not just mapping, but also it triggers on cpufreq transitions
> Right, but I'm not sure that's the most important aspect of this governor.

What are the other events triggering it, then?

>> Which makes me wonder if the approach here is the right one at all.
>> Shouldn't the cpufreq driver be hooked up to the related HW through
>> the OPP framework and sharing access with devfreq rather?
> Not sure what you mean here. This devfreq governor is orthogonal to what the
> cpufreq driver does with its HW. This is just trying to scale L3 or DDR or
> whatever other device based on current CPU frequency. Not all CPUfreq
> drivers support OPP. And even if they do, I don't see how it's relevant
> here.

OK, fair enough.

 \ /
  Last update: 2018-08-01 09:31    [W:0.071 / U:0.292 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site