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
| ||
|
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
Powered by blists - more mailing lists