Messages in this thread | | | Date | Wed, 6 Sep 2023 22:52:20 +0100 | From | Qais Yousef <> | Subject | Re: [RFC PATCH 5/7] sched/schedutil: Add a new tunable to dictate response time |
| |
On 09/06/23 23:13, Dietmar Eggemann wrote: > On 28/08/2023 01:32, Qais Yousef wrote: > > [...] > > > @@ -427,6 +427,23 @@ This governor exposes only one tunable: > > The purpose of this tunable is to reduce the scheduler context overhead > > of the governor which might be excessive without it. > > > > +``respone_time_ms`` > > + Amount of time (in milliseconds) required to ramp the policy from > > + lowest to highest frequency. Can be decreased to speed up the > > + responsiveness of the system, or increased to slow the system down in > > + hope to save power. The best perf/watt will depend on the system > > + characteristics and the dominant workload you expect to run. For > > + userspace that has smart context on the type of workload running (like > > + in Android), one can tune this to suite the demand of that workload. > > + > > + Note that when slowing the response down, you can end up effectively > > + chopping off the top frequencies for that policy as the util is capped > > + to 1024. On HMP systems where some CPUs have a capacity less than 1024, > > HMP isn't used in mainline AFAIK. IMHO, the term `asymmetric CPU > capacity` systems is used.
It's a shorter name and less mouthful and typeful; I think we should start to use it :)
> > [...] > > > @@ -59,6 +61,45 @@ static DEFINE_PER_CPU(struct sugov_cpu, sugov_cpu); > > > > /************************ Governor internals ***********************/ > > > > +static inline u64 sugov_calc_freq_response_ms(struct sugov_policy *sg_policy) > > +{ > > + int cpu = cpumask_first(sg_policy->policy->cpus); > > + unsigned long cap = capacity_orig_of(cpu); > > + > > + return approximate_runtime(cap); > > +} > > I can see the potential issue of schedutil being earlier initialized > than the `max frequency scaling of cpu_capacity_orig` happens in > drivers/base/arch_topology.c. > > So the response_time_ms setup for a little CPU on Juno-r0 wouldn't > happen on cpu_capacity_orig = 446 -> 26ms but on on the raw capacity > value from dt: > > capacity-dmips-mhz = <578> > > So I would expect to see t = 32ms * ln(1 - 578/1024)/ln(0.5) = 38ms instead. > > We have a similar dependency between `max frequency scaled > cpu_capacity_orig` and the EM setup code.
Hmm thanks for the pointer! That might help explain why I see wrong values for the big core in my setup.
Should using arch_scale_cpu_capacity() help instead? Or I need to find a way to plug the race instead?
Thanks!
-- Qais Yousef
| |