On Mon, Sep 6, 2021 at 2:53 PM Vincent Donnefort
[off-list ref] wrote:

On Mon, Sep 06, 2021 at 02:08:36PM +0200, Rafael J. Wysocki wrote:

quoted

On Mon, Sep 6, 2021 at 10:17 AM Vincent Donnefort
[off-list ref] wrote:

quoted

[...]

quoted

quoted

quoted

Moreover, if only efficient frequencies are to be used, RELATION_L
needs to return min(policy->max, the closest efficient frequency equal
to or above the target).

You mean, never returning an inefficient frequency, unless there are no
efficient ones in the range policy->min policy->max ?

No, that's not what I mean.

First note that the target here is clamped between the policy min and
max.  Also bear in mind that each of them is a frequency from the
table, either efficient or inefficient.

In the first step, search through the efficient frequencies only.
That will return you something at or above the target.  If it is at
the target, you're done.  If it is above the target, it may be either
within or above the policy max.  If it is within the policy max,
you're done.  If it is above the policy max, you need to search
through the inefficient frequencies between the target and the policy
max (and you know that there is at least one - the policy max itself).

So what I said previously wasn't particularly precise, sorry about that.

I might have missed something but it seems equivalent to what's currently done:

Find the appropriate frequency, if inefficient go to the efficient one, if
above policy->max return the original inefficient frequency.

It may or may not be equivalent depending on what the efficient one is.

And what is there now doesn't work for RELATION_H if I'm not mistaken.

With the current approach, RELATION_H would find the best frequency and then
resolve it to an efficient one if possible. The efficient one might overshoot
the target_freq, but isn't it a good thing ?

No, it cannot.

 - If we consider only the efficient freqs in a first place, there's a risk we
   would return a frequency way smaller than the actual request.

 - What are the gain in capping RELATION_H to the target_freq if we can find a
   frequency higher than the request that wouldn't use more energy than the
   target?

There may be a power constraint, so RELATION_H should never go above the target.

RELATION_H is used in two DVFS governors: conservative and ondemand:

  - Ondemand is using RELATION_H in the context of powerbias. It seems a usecase
    where it is not a problem to overshoot RELATION_H.

  - Conservative is using RELATION_H when the load is increasing. Same as
    ondemand, I don't think we would have any gain by not overshooting the
    RELATION_H target.

Well, let me repeat: the performance governor uses RELATION_H, so if
you allow it to go above the policy limit, it will stay there forever.