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 >