On Thu, Sep 2, 2021 at 3:49 PM Vincent Donnefort
[off-list ref] wrote:

[...]

quoted

quoted

quoted

quoted

+static inline unsigned int
+cpufreq_frequency_find_efficient(struct cpufreq_policy *policy,
+                                unsigned int idx)
+{
+       struct cpufreq_frequency_table *table = policy->freq_table;
+       unsigned int efficient_idx = table[idx].efficient;
+
+       return table[efficient_idx].frequency <= policy->max ? efficient_idx :
+               idx;

I'm not sure about this.

In the _RELATION_L case table[idx].frequency can be above the policy
max, so you may end up running at an inefficient frequency above the
policy max, but you won't use an efficient one above it.  Isn't this
slightly confusing?

This can indeed happen when policy->max isn't equal to an available frequency.
But nontheless, we can't let the efficient resolution violate the policy->max,
which is used for thermal capping. The fact that we can overshoot a max
limit is confusing as well.

So I could add a policy->max sanity, to make sure this value is an actual
frequency and that RELATION_L will never overshoot that value. Or we can have a
flag somewhere to indicate thermal capping is happening and we shouldn't skip
inefficient frequencies.

I would prefer the first option, because user space may be applying
the limit for power capping or thermal reasons too and the kernel
can't really tell why it is doing that.

This needs to be added to cpufreq_set_policy(), I think after calling
the driver's ->verify().

And if this is done to the policy max, IMO it needs to be done to the
policy min too, for consistency.  So if a frequency table is used, the
policy max and the policy min could be only the frequencies present in
the table.

Ack. I'll consolidate policy->max and ->min set behavior in v7 so we won't have
any problem having to know who set policy->max and if yes or no we can break it.

What relation do we want for min/max setting? I guess RELATION_H for policy->max
and RELATION_L for policy->min (i.e. The highest frequency existing right below
the maximum and the lowest frequency existing just above the minimum)

Yes.

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.