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

From: Dietmar Eggemann <dietmar.eggemann@arm.com>
To: Qais Yousef <qyousef@layalina.io>, Ingo Molnar <mingo@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Viresh Kumar <viresh.kumar@linaro.org>,
	Vincent Guittot <vincent.guittot@linaro.org>
Cc: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org,
	Lukasz Luba <lukasz.luba@arm.com>
Subject: Re: [RFC PATCH 5/7] sched/schedutil: Add a new tunable to dictate response time
Date: Wed, 6 Sep 2023 23:13:01 +0200	[thread overview]
Message-ID: <60a21021-87c5-b93d-4312-d41fbcd4ec43@arm.com> (raw)
In-Reply-To: <20230827233203.1315953-6-qyousef@layalina.io>

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.

[...]

> @@ -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.

[...]