linux-kernel - Re: [PATCH v3 1/2] PM / devfreq: Generic CPU frequency to device frequency mapping governor

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: <35ff3e303f5de9980979b49c89f9a687@codeaurora.org>
Date:   Mon, 06 Aug 2018 22:49:48 -0700
From:   skannan@...eaurora.org
To:     myungjoo.ham@...sung.com
Cc:     Kyungmin Park <kyungmin.park@...sung.com>,
        Chanwoo Choi <cw00.choi@...sung.com>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>, georgi.djakov@...aro.org,
        vincent.guittot@...aro.org, daidavid1@...eaurora.org,
        bjorn.andersson@...aro.org, linux-pm@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 1/2] PM / devfreq: Generic CPU frequency to device
 frequency mapping governor

On 2018-08-02 14:00, skannan@...eaurora.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