linux-kernel - Re: cpufreq: intel_pstate: map utilization into the pstate range

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]

Date:   Tue, 28 Dec 2021 19:06:44 +0100
From:   "Rafael J. Wysocki" <rafael@...nel.org>
To:     Julia Lawall <julia.lawall@...ia.fr>
Cc:     "Rafael J. Wysocki" <rafael@...nel.org>,
        Francisco Jerez <currojerez@...eup.net>,
        Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>,
        Len Brown <lenb@...nel.org>,
        Viresh Kumar <viresh.kumar@...aro.org>,
        Linux PM <linux-pm@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Ingo Molnar <mingo@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Juri Lelli <juri.lelli@...hat.com>,
        Vincent Guittot <vincent.guittot@...aro.org>
Subject: Re: cpufreq: intel_pstate: map utilization into the pstate range

On Tue, Dec 28, 2021 at 6:46 PM Julia Lawall <julia.lawall@...ia.fr> wrote:
>
>
>
> On Tue, 28 Dec 2021, Rafael J. Wysocki wrote:
>
> > On Tue, Dec 28, 2021 at 5:58 PM Julia Lawall <julia.lawall@...ia.fr> wrote:
> > >
> > > I looked a bit more into why pstate 20 is always using the least energy. I
> > > have just one thread spinning for 10 seconds, I use a fixed value for the
> > > pstate, and I measure the energy usage with turbostat.
> >
> > How exactly do you fix the pstate?
>
> diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c
> index e7af18857371..19440b15454c 100644
> --- a/kernel/sched/cpufreq_schedutil.c
> +++ b/kernel/sched/cpufreq_schedutil.c
> @@ -400,7 +402,7 @@ static void sugov_update_single_perf(struct update_util_data *hook, u64 time,
>                 sg_cpu->util = prev_util;
>
>         cpufreq_driver_adjust_perf(sg_cpu->cpu, map_util_perf(sg_cpu->bw_dl),
> -                                  map_util_perf(sg_cpu->util), sg_cpu->max);
> +                                  sysctl_sched_fixedfreq, sg_cpu->max);

This is just changing the "target" hint given to the processor which
may very well ignore it, though.

>
>         sg_cpu->sg_policy->last_freq_update_time = time;
>  }
>
> ------------------------------
>
> sysctl_sched_fixedfreq is a variable that I added to sysfs.

If I were trying to fix a pstate, I would set scaling_max_freq and
scaling_min_freq in sysfs for all CPUs to the same value.

That would cause intel_pstate to set HWP min and max to the same value
which should really cause the pstate to be fixed, at least outside the
turbo range of pstates.

> >
> > > I tried this on a
> > > 2-socket Intel 6130 and a 4-socket Intel 6130.  The experiment runs 40
> > > times.
> > >
> > > There seem to be only two levels of CPU energy usage.  On the 2-socket
> > > machine the energy usage is around 600J up to pstate 20 and around 1000J
> > > after that.  On the 4-socket machine it is twice that.
> >
> > These are the package power numbers from turbostat, aren't they?
>
> Yes.

OK