[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20231211000809.qostlrd5bka6cvak@airbuntu>
Date: Mon, 11 Dec 2023 00:08:09 +0000
From: Qais Yousef <qyousef@...alina.io>
To: 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>,
Dietmar Eggemann <dietmar.eggemann@....com>
Cc: linux-kernel@...r.kernel.org, linux-pm@...r.kernel.org,
Lukasz Luba <lukasz.luba@....com>, Wei Wang <wvw@...gle.com>,
Rick Yiu <rickyiu@...gle.com>,
Chung-Kai Mei <chungkai@...gle.com>,
Hongyan Xia <hongyan.xia2@....com>
Subject: Re: [PATCH 2/4] sched/uclamp: Remove rq max aggregation
On 12/08/23 01:52, Qais Yousef wrote:
> +/* Request freq update on context switch if necessary */
> +static inline void uclamp_context_switch(struct rq *rq)
> {
> - return static_branch_likely(&sched_uclamp_used);
> + unsigned long uclamp_min;
> + unsigned long uclamp_max;
> + unsigned long util;
> +
> + /* Only RT and FAIR tasks are aware of uclamp */
> + if (!rt_policy(current->policy) && !fair_policy(current->policy))
> + return;
We have a dependency on min_granularity_ns (or base_slice_ns) here that
I forgot to add before posting.
If our base_slice_ns is smaller than dvfs_update_delay, then tasks won't run
long enough for the hardware to apply their performance hints before they get
context switched out.
Beside the new proposed sched_runtime being able to request a smaller slice; in
practice default base_slice_ns is okay-ish.
> +
> + uclamp_min = uclamp_eff_value(current, UCLAMP_MIN);
> + uclamp_max = uclamp_eff_value(current, UCLAMP_MAX);
> + util = rq->cfs.avg.util_avg;
> +
> + if (uclamp_min > util || uclamp_max < util)
> + cpufreq_update_util(rq, SCHED_CPUFREQ_PERF_HINTS);
> }
Powered by blists - more mailing lists