Re: [PATCH 2/2] sched/cpufreq: Update schedutil's DVFS request to reach the boost frequencies

Vincent Guittot <[email protected]>
Newsgroups org.kernel.vger.linux-pm,org.kernel.vger.linux-arm-msm,org.kernel.vger.linux-kernel
Message-ID <CAKfTPtBoevmq8_Rens2Le=AGqMZRo56oD4eMGX2_2Pj_Vt9zCg@mail.gmail.com>
On Thu, 6 Aug 2026 at 11:02, Christian Loehle <[email protected]> wrote:
>
> On 8/6/26 05:42, Sibi Sankar wrote:
> > capacity_freq_ref, exposed to schedutil via get_capacity_ref_freq(),
> > was introduced by commit 9942cb22ea45 ("sched/topology: Add a new
> > arch_scale_freq_ref() method") as a fixed anchor that does not move at
> > runtime. However, schedutil uses that same fixed anchor as the reference
> > plugged into map_util_freq() which saturates exactly at capacity_freq_ref.
> >
> > As a result, a system with cpufreq boost enabled effectively never runs at
> > boost frequencies under schedutil-governed load. Fix this by plugging in
> > policy-max into the map_util_freq equation, so that the DVFS requests
> > translates to the actual cpufreq driver ceiling.
> >
> > Signed-off-by: Sibi Sankar <[email protected]>
> > ---
> >  kernel/sched/cpufreq_schedutil.c | 13 ++++++++++---
> >  1 file changed, 10 insertions(+), 3 deletions(-)
> >
> > diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c
> > index a1782755efcc..dcefbeaa0702 100644
> > --- a/kernel/sched/cpufreq_schedutil.c
> > +++ b/kernel/sched/cpufreq_schedutil.c
> > @@ -195,10 +195,17 @@ static unsigned int get_next_freq(struct sugov_policy *sg_policy,
> >                                 unsigned long util, unsigned long max)
> >  {
> >       struct cpufreq_policy *policy = sg_policy->policy;
> > -     unsigned int freq;
> > +     unsigned int freq, ref;
> >
> > -     freq = get_capacity_ref_freq(policy);
> > -     freq = map_util_freq(util, freq, max);
> > +     ref = get_capacity_ref_freq(policy);
> > +
> > +     /*
> > +      * That fixed anchor governs how utilization is interpreted, but
> > +      * the DVFS request is free to target the current policy ceiling.
> > +      * Using ref alone would saturate the util->freq map at ref so
> > +      * use policy->max to reach boost frequencies.
>
> I'm not sure those two statements are compatible with the implementation below?
> util / max is expressed in the capacity scale established using ref, multiplying
> that ratio by policy->max changes the interpretation of every util value.
>
>
> > +      */
> > +     freq = map_util_freq(util, max(ref, READ_ONCE(policy->max)), max);
>
> Isn't the underlying problem that schedutil can't handle requests above capacity 1024?
>
> effective_cpu_util() caps util at max, and sugov_effective_cpu_perf() applies
> the 25% headroom before clipping the result back to that same value.
> Therefore the input here cannot exceed 1024, and mapping it against ref
> can never request a frequency above ref.
> Using policy->max makes boost reachable, but also stretches the complete frequency range.
> For example, with ref = 4454400, policy->max = 4723200, and effective util 640, the request
> changes from 2784000 to 2952000.
>
> Making 'boost frequencies' truly compatible with schedutil (or PELT/CAS for that matter)
> is a discussion that is yet to be had?
> See also
> https://lore.kernel.org/lkml/[email protected]/

cpufreq_pressure and freq_qos_update_request could handle the case
where boost freq is used as the ref freq when setting capacity but
disabled. I can't remember if everything was already in place when we
discussed this last time

>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.