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]

Message-ID: <alpine.DEB.2.22.394.2112301919240.15550@hadrien>
Date:   Thu, 30 Dec 2021 19:20:46 +0100 (CET)
From:   Julia Lawall <julia.lawall@...ia.fr>
To:     "Rafael J. Wysocki" <rafael@...nel.org>
cc:     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 Thu, 30 Dec 2021, Rafael J. Wysocki wrote:

> On Thu, Dec 30, 2021 at 6:54 PM Julia Lawall <julia.lawall@...ia.fr> wrote:
> >
> > > > The effect is the same.  But that approach is indeed simpler than patching
> > > > the kernel.
> > >
> > > It is also applicable when intel_pstate runs in the active mode.
> > >
> > > As for the results that you have reported, it looks like the package
> > > power on these systems is dominated by package voltage and going from
> > > P-state 20 to P-state 21 causes that voltage to increase significantly
> > > (the observed RAM energy usage pattern is consistent with that).  This
> > > means that running at P-states above 20 is only really justified if
> > > there is a strict performance requirement that can't be met otherwise.
> > >
> > > Can you please check what value is there in the base_frequency sysfs
> > > attribute under cpuX/cpufreq/?
> >
> > 2100000, which should be pstate 21
> >
> > >
> > > I'm guessing that the package voltage level for P-states 10 and 20 is
> > > the same, so the power difference between them is not significant
> > > relative to the difference between P-state 20 and 21 and if increasing
> > > the P-state causes some extra idle time to appear in the workload
> > > (even though there is not enough of it to prevent to overall
> > > utilization from increasing), then the overall power draw when running
> > > at P-state 10 may be greater that for P-state 20.
> >
> > My impression is that the package voltage level for P-states 10 to 20 is
> > high enough that increasing the frequency has little impact.  But the code
> > runs twice as fast, which reduces the execution time a lot, saving energy.
> >
> > My first experiment had only one running thread.  I also tried running 32
> > spinning threads for 10 seconds, ie using up one package and leaving the
> > other idle.  In this case, instead of staying around 600J for pstates
> > 10-20, the pstate rises from 743 to 946.  But there is still a gap between
> > 20 and 21, with 21 being 1392J.
> >
> > > You can check if there is any C-state residency difference between
> > > these two cases by running the workload under turbostat in each of
> > > them.
> >
> > The C1 and C6 cases (CPU%c1 and CPU%c6) are about the same between 20 and
> > 21, whether with 1 thread or with 32 thread.
>
> I meant to compare P-state 10 and P-state 20.
>
> 20 and 21 are really close as far as the performance is concerned, so
> I wouldn't expect to see any significant C-state residency difference
> between them.

There's also no difference between 10 and 20.  This seems normal, because
the same cores are either fully used or fully idle in both cases.  The
idle ones are almost always in C6.

julia