linux-kernel - Re: [RFT][PATCH v1 3/8] cpufreq/sched: Allow .setpolicy() cpufreq drivers to enable EAS

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: <CAJZ5v0jxoKaGOsXqUqd=n95ATxzDTueSy_je_ktxOdm6B=+20A@mail.gmail.com>
Date: Thu, 17 Apr 2025 15:01:12 +0200
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: Christian Loehle <christian.loehle@....com>
Cc: "Rafael J. Wysocki" <rjw@...ysocki.net>, Linux PM <linux-pm@...r.kernel.org>, 
	LKML <linux-kernel@...r.kernel.org>, Lukasz Luba <lukasz.luba@....com>, 
	Peter Zijlstra <peterz@...radead.org>, 
	Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>, 
	Dietmar Eggemann <dietmar.eggemann@....com>, Morten Rasmussen <morten.rasmussen@....com>, 
	Vincent Guittot <vincent.guittot@...aro.org>, 
	Ricardo Neri <ricardo.neri-calderon@...ux.intel.com>, 
	Pierre Gondois <pierre.gondois@....com>
Subject: Re: [RFT][PATCH v1 3/8] cpufreq/sched: Allow .setpolicy() cpufreq
 drivers to enable EAS

On Thu, Apr 17, 2025 at 2:19 PM Christian Loehle
<christian.loehle@....com> wrote:
>
> On 4/16/25 19:01, Rafael J. Wysocki wrote:
> > From: Rafael J. Wysocki <rafael.j.wysocki@...el.com>
> >
> > Some cpufreq drivers, like intel_pstate, have built-in governors that
> > are used instead of regular cpufreq governors, schedutil in particular,
> > but they can work with EAS just fine, so allow EAS to be used with
> > those drivers.
> >
> > Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@...el.com>
> > ---
> >
> > v0.3 -> v1
> >      * Rebase on top of the new [1-2/8].
> >      * Update the diagnostic message printed if the conditions are not met.
> >
> > This patch is regarded as a cleanup for 6.16.
> >
> > ---
> >  drivers/cpufreq/cpufreq.c |   13 +++++++++++--
> >  1 file changed, 11 insertions(+), 2 deletions(-)
> >
> > --- a/drivers/cpufreq/cpufreq.c
> > +++ b/drivers/cpufreq/cpufreq.c
> > @@ -3054,7 +3054,16 @@
> >
> >       guard(cpufreq_policy_read)(policy);
> >
> > -     return sugov_is_governor(policy);
> > +     /*
> > +      * For EAS compatibility, require that either schedutil is the policy
> > +      * governor or the policy is governed directly by the cpufreq driver.
> > +      *
> > +      * In the latter case, it is assumed that EAS can only be enabled by the
> > +      * cpufreq driver itself which will not enable EAS if it does not meet
> > +      * the EAS' expectations regarding performance scaling response.
> > +      */
> > +     return sugov_is_governor(policy) || (!policy->governor &&
> > +             policy->policy != CPUFREQ_POLICY_UNKNOWN);
> >  }
> >
> >  bool cpufreq_ready_for_eas(const struct cpumask *cpu_mask)
> > @@ -3064,7 +3073,7 @@
> >       /* Do not attempt EAS if schedutil is not being used. */
> >       for_each_cpu(cpu, cpu_mask) {
> >               if (!cpufreq_policy_is_good_for_eas(cpu)) {
> > -                     pr_debug("rd %*pbl: schedutil is mandatory for EAS\n",
> > +                     pr_debug("rd %*pbl: EAS requirements not met\n",
> >                                cpumask_pr_args(cpu_mask));
>
> I'd prefer to have at least "EAS cpufreq requirements" printed here.

Sure.

> with that caveat
> Reviewed-by: Christian Loehle <christian.loehle@....com>
>
> Maybe we should amend the EAS documentation to reflect this?

Yes, the documentation should be updated.  Which piece of it in
particular I need to look at?

> (And also emphasise that EAS will make cpufreq assumptions as if sugov
> was the governor regardless.)

Right.