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, 24 Nov 2015 02:09:36 +0100
From:	"Rafael J. Wysocki" <rafael@...nel.org>
To:	Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>,
	Alexandra Yates <alexandra.yates@...ux.intel.com>
Cc:	Len Brown <lenb@...nel.org>,
	Viresh Kumar <viresh.kumar@...aro.org>,
	"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>
Subject: Re: [PATCH V3] SKL intel_pstate update MSR values when changing governors

Hi,

On Sat, Nov 21, 2015 at 1:16 AM, Srinivas Pandruvada
<srinivas.pandruvada@...ux.intel.com> wrote:
>
>
> On 11/18/2015 02:58 PM, Alexandra Yates wrote:
>>
>> When changing from powersave to performance governors
>> Intel_pstate fails to update the MSR values that reflect the
>> max_perf_pct to 100%. For instance in SKL reading rdmsr 0x774:
>>
>> Governor        MSR                     max_perf_pct
>> =========       ========                ============
>> Powersave       80002808                100%
>> Powersave       80002008                80%
>> Performance     80002028 [error]        100%
>> Performance     80002828 [expected]     100%
>>
>> The line label [error] shows the culprit. At this point the MSR
>> should reflect the max_perf_pct that is 100%, that corresponds
>> to MSR 80002828 as shown on the next line of the example. Which
>> is the maximum performance for the Performance governor.
>> Instead it holds back the MSR value previously set by the
>> Powersave, in this case 80002028.
>>
>> This patch allows the system to print the correct MSR value
>> 80002828 that corresponds to the 100% max_perf_pct when changing
>> from powersave to performance governors.

Is this only about what is printed or does it mean that the driver
actually uses an incorrect MSR value?

>> For more information on the MSR values for SKL please visit
>> ISDM under Managing HWP.
>>
>> Signed-off-by: Alexandra Yates <alexandra.yates@...ux.intel.com>
>
> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>
>>
>> ---
>>   drivers/cpufreq/intel_pstate.c | 2 ++
>>   1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/cpufreq/intel_pstate.c
>> b/drivers/cpufreq/intel_pstate.c
>> index 2e31d09..0eeb7da 100644
>> --- a/drivers/cpufreq/intel_pstate.c
>> +++ b/drivers/cpufreq/intel_pstate.c
>> @@ -1242,6 +1242,8 @@ static int intel_pstate_set_policy(struct
>> cpufreq_policy *policy)
>>             policy->max >= policy->cpuinfo.max_freq) {
>>                 pr_debug("intel_pstate: set performance\n");
>>                 limits = &performance_limits;
>> +               if (hwp_active)
>> +                       intel_pstate_hwp_set();

Honestly, I'm not really sure how this is matching the changelog.

What it does is to ensure that the correct limits are used when in the
HWP mode too as far as I can say.  Is my understanding correct here?

>>                 return 0;
>>         }
>>
>>
> --

Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists