linux-kernel - RE: [PATCH v2] cpufreq: intel_pstate: Generic governors support

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-next>] [day] [month] [year] [list]

Message-ID: <000301d240f7$d86604b0$89320e10$@net>
Date:   Thu, 17 Nov 2016 09:27:15 -0800
From:   "Doug Smythies" <dsmythies@...us.net>
To:     "'Rafael J. Wysocki'" <rjw@...ysocki.net>,
        "'Srinivas Pandruvada'" <srinivas.pandruvada@...ux.intel.com>
Cc:     "'Linux Kernel Mailing List'" <linux-kernel@...r.kernel.org>,
        "'Linux PM list'" <linux-pm@...r.kernel.org>
Subject: RE: [PATCH v2] cpufreq: intel_pstate: Generic governors support

On 2016.11.15 18:35 Rafael J. Wysocki wrote:

> -> v2:
> Notice that intel_cpufreq_target() generally can be called on a CPU
> different from the target one, so it needs to ensure that the right
> MSR will be written, so update the code accordingly.  This makes
> the performance and powersave governors work with this driver as
> expected (at least).

With V2 I did the exact same tests with the ondemand, powersave,
and performance governors as I did with the previous versions 
of this patch. Now everything works fine and as expected.

Thanks.

Also from this previous reply to 
"[RFC/RFT][PATCH] cpufreq: intel_pstate: Generic governors support":

On 2016.11.01 17:14 Srinivas Pandruvada wrote:
> On Tue, 2016-11-01 at 14:11 -0700, Doug Smythies wrote:
>> On 2016.10.22 17:17 Rafael J. Wysocki wrote: 
>> 
>> It is not clear to me why users that currently use
>> intel_pstate=disable on the kernel command line would benefit from
>> this change.
> Two reasons I think:
> - We have a big turbo zone, where current acpi-cpufreq can't select any
> target frequency even if controllable.
>
> - We can still target ACPI-CPPC compatible devices in legacy mode and
> later in non-legacy mode.

V2 also fixes the test results (I was using clock modulation as
my test case), that caused me to erroneously think there would
be no benefit from intel_pstate=passive over intel_pstate=disable
in cases where the user has to use disable for proper operation.

... Doug