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

[Sibi Sankar]

Hi Saravana,

On 2018-08-07 11:19, skannan@xxxxxxxxxxxxxx wrote:
> On 2018-08-02 14:00, skannan@xxxxxxxxxxxxxx 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.

With the cpu-freq driver for SDM845 SoC supporting fast_switch and 
schedutil supporting
dynamic switching wouldn't this governor be incompatible due to its 
reliance on transition
notifiers? Is it planned to be used only with ondemand/performance 
governors?

> > > > 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

--
-- Sibi Sankar --
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project.