linux-kernel - Re: [PATCH] cpufreq: intel_pstate: Implement passive mode with HWP enabled

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: <CAJZ5v0hm-evY87JkG=Aru2Z_gFwcjB7XD+pJgM4iMSQJkrmtrw@mail.gmail.com>
Date:   Thu, 16 Jul 2020 16:33:34 +0200
From:   "Rafael J. Wysocki" <rafael@...nel.org>
To:     Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>
Cc:     Francisco Jerez <currojerez@...eup.net>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>,
        Linux PM <linux-pm@...r.kernel.org>,
        Linux Documentation <linux-doc@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Giovanni Gherdovich <ggherdovich@...e.cz>,
        Doug Smythies <dsmythies@...us.net>
Subject: Re: [PATCH] cpufreq: intel_pstate: Implement passive mode with HWP enabled

On Thu, Jul 16, 2020 at 3:14 AM Srinivas Pandruvada
<srinivas.pandruvada@...ux.intel.com> wrote:
>
> On Wed, 2020-07-15 at 14:35 -0700, Francisco Jerez wrote:
> > "Rafael J. Wysocki" <rafael@...nel.org> writes:
> >
> > > On Wed, Jul 15, 2020 at 2:09 AM Francisco Jerez <
> > > currojerez@...eup.net> wrote:
> > > > "Rafael J. Wysocki" <rjw@...ysocki.net> writes:
> > > >
> > > > > From: Rafael J. Wysocki <rafael.j.wysocki@...el.com>
> > > > >
>
> [...]
>
> > > > > I don't think that's accurate.  I've looked at hundreds of
> > > > > traces
> > while
> > my series [1] was in control of HWP_REQ_MAX and I've never seen an
> > excursion above the maximum HWP_REQ_MAX control specified by it
> > within a
> > given P-state domain, even while that maximum specified was well into
> > the turbo range.  So, yeah, I agree that HWP_REQ_MAX is nothing like
> > a
> > hard limit, particularly when multiple threads are running on the
> > same
> > clock domain, but the processor will still make its best effort to
> > limit
> > the clock frequency to the maximum of the requested maximums, even if
> > it
> > happens to be within the turbo range.  That doesn't make it useless.
> > The exact same thing can be said about controlling HWP_REQ_MIN as
> > you're
> > doing now in this revision of your patch, BTW.
> >
> > If you don't believe me here is the turbostat sample with maximum
> > Bzy_MHz I get on the computer I'm sitting on right now while
> > compiling a
> > kernel on CPU0 if I set HWP_REQ_MAX to 0x1c (within the turbo range):
> >
> > > Core    CPU     Avg_MHz
> > > Busy%   Bzy_MHz            HWP_REQ      PkgWatt CorWatt
> > > -       -       757     27.03   2800    0x0000000000000000      7.1
> > > 3    4.90
> > > 0       0       2794    99.77   2800    0x0000000080001c04      7.1
> > > 3    4.90
> > > 0       2       83      2.98    2800    0x0000000080001c04
> > > 1       1       73      2.60    2800    0x0000000080001c04
> > > 1       3       78      2.79    2800    0x0000000080001c04
> >
> > With the default HWP_REQUEST:
> >
> > > Core    CPU     Avg_MHz
> > > Busy%   Bzy_MHz            HWP_REQ      PkgWatt CorWatt
> > > -       -       814     27.00   3015    0x0000000000000000      8.4
> > > 9    6.18
> > > 0       0       2968    98.24   3021    0x0000000080001f04      8.4
> > > 9    6.18
> > > 0       2       84      2.81    2982    0x0000000080001f04
> > > 1       1       99      3.34    2961    0x0000000080001f04
> > > 1       3       105     3.60    2921    0x0000000080001f04
>
> Correct. In HWP mode this is possible to lower limit in turbo region
> conditionally. In legacy mode you can't with turbo activation ratio.
>
> But what we don't want set max and min perf and use like desired to run
> at a P-state overriding HWP or limit the range where HWP can't do any
> meaningful selection.

That's a good point too IMO.