Re: [RFC][PATCH 0/3] New thermal interface allowing IPA to get max power

[Daniel Lezcano]

Hi Lukasz,

sorry for the delay, it took more time to finish my current work before
commenting these patches.

On 26/01/2021 11:39, Lukasz Luba wrote:
> Hi all,
> 
> This patch set tries to add the missing feature in the Intelligent Power
> Allocation (IPA) governor which is: frequency limit set by user space.

It is unclear if we are talking about frequency limit of the dvfs device
by setting the hardware limit (min-max freq). If it is the case, then
that is an energy model change, and all user of the energy model must be
notified about this change. But I don't see why userspace wants to
change that.

If we just want to set a frequency limit, then that is what we are doing
with the DTPM framework via power numbers.

> User can set max allowed frequency for a given device which has impact on
> max allowed power. In current design there is no mechanism to figure this
> out. IPA must know the maximum allowed power for every device. It is then
> used for proper power split and divvy-up. When the user limit for max
> frequency is not know, IPA assumes it is the highest possible frequency.
> It causes wrong power split across the devices.

That is because the IPA introduced the power rebalancing between devices
belonging the same thermal zone, so the feature was very use case specific.

The DTPM is supposed to solve this by providing an unified uW unit to
act on the different power capable devices on a generic way.

Today DTPM is mapped to userspace using the powercap framework, but it
is considered to add kernel API to let other subsystem to act on it
directly. May be, you can add those and call them from IPA directly, so
the governor does power decision and ask the DTPM to do the changes.

Conceptually, that would be much more consistent and will remove
duplicated code IMO.

May be create a power_qos framework to unify the units ...

> This new mechanism provides the max allowed frequency to the thermal
> framework and then max allowed power to the IPA.
> The implementation is done in this way because currently there is no way
> to retrieve the limits from the PM QoS, without uncapping the local
> thermal limit and reading the next value. It would be a heavy way of
> doing these things, since it should be done every polling time (e.g. 50ms).
>
> Also, the value stored in PM QoS can be different than the real OPP 'rate'
> so still would need conversion into proper OPP for comparison with EM.
> Furthermore, uncapping the device in thermal just to check the user freq
> limit is not the safest way.
> Thus, this simple implementation moves the calculation of the proper
> frequency to the sysfs write code, since it's called less often. The value
> is then used as-is in the thermal framework without any hassle.

Sounds like the DTPM is doing exactly that, no ?

> As it's a RFC, it still misses the cpufreq sysfs implementation, but would
> be addressed if all agree.
We are talking about power, frequency, in-kernel governor, userspace
having knowledge of max frequency limit to set power.

I'm a bit lost. What is the problem we want to solve here ?

May be I'm missing something. Is it possible to share a scenario where
the userspace acts on the devfreq and the IPA taking decision to
illustrate your proposal ?


-- 
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog