linux-kernel - Re: [PATCH 1/2] cpufreq, intel_pstate, Fix limits->max_policy

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

Message-ID: <1448063875.9857.6.camel@intel.com>
Date:	Fri, 20 Nov 2015 23:57:56 +0000
From:	"Pandruvada, Srinivas" <srinivas.pandruvada@...el.com>
To:	"prarit@...hat.com" <prarit@...hat.com>
CC:	"Brown, Len" <len.brown@...el.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"viresh.kumar@...aro.org" <viresh.kumar@...aro.org>,
	"kristen@...ux.intel.com" <kristen@...ux.intel.com>,
	"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
	"rjw@...ysocki.net" <rjw@...ysocki.net>,
	"Yates, Alexandra" <alexandra.yates@...el.com>
Subject: Re: [PATCH 1/2] cpufreq, intel_pstate, Fix limits->max_policy_pct
 rounding error

On Fri, 2015-11-20 at 18:47 -0500, Prarit Bhargava wrote:
> 
[cut]
> The -1 difference here is not unexpected given the other probable rounding
> errors in the frequency code.
Yes. Intel P state cpufreq interface is not optimal. We even debate
whether we should have this interface at all.

>   I have a feeling that no one really has done an
> in depth review to find the errors.  I'm not going to because I'm pretty sure
> I/we can convince users that 3200 == 3199.98 ;).  FWIW, I've also wondered if
> the difference between the marketing frequency and the TSC frequency (which in
> theory equals the marketing frequency) can cause this sort of error.
We don't even request correct pstate here, so we will not get that. But
in this case in turbo region is not controllable (after Sandybridge )
above something called turbo activation ratio. So not a big deal.
As long as we can set at lower end we are fine.
> 

Thanks,
Srinivas

> OOC did you try loading the system down (with a kernel build) and switching
> between frequencies?  That's a good way to see the effect of the turbo states.
> I would expect that the turbo state hits a maximum of about 75% of the max turbo
> state value (based on experiment) so the differences should be larger at the
> high end.
> 
> P.