linux-kernel - Re: [RFC PATCH 5/7] sched/schedutil: Add a new tunable to dictate response time

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20230906215220.65em2kgyr76s7sz2@airbuntu>
Date:   Wed, 6 Sep 2023 22:52:20 +0100
From:   Qais Yousef <qyousef@...alina.io>
To:     Dietmar Eggemann <dietmar.eggemann@....com>
Cc:     Ingo Molnar <mingo@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        Viresh Kumar <viresh.kumar@...aro.org>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        linux-kernel@...r.kernel.org, linux-pm@...r.kernel.org,
        Lukasz Luba <lukasz.luba@....com>
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