From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760744AbbKTX6A (ORCPT ); Fri, 20 Nov 2015 18:58:00 -0500 Received: from mga11.intel.com ([192.55.52.93]:14494 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759681AbbKTX56 (ORCPT ); Fri, 20 Nov 2015 18:57:58 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,325,1444719600"; d="scan'208";a="843854196" From: "Pandruvada, Srinivas" To: "prarit@redhat.com" CC: "Brown, Len" , "linux-kernel@vger.kernel.org" , "viresh.kumar@linaro.org" , "kristen@linux.intel.com" , "linux-pm@vger.kernel.org" , "rjw@rjwysocki.net" , "Yates, Alexandra" Subject: Re: [PATCH 1/2] cpufreq, intel_pstate, Fix limits->max_policy_pct rounding error Thread-Topic: [PATCH 1/2] cpufreq, intel_pstate, Fix limits->max_policy_pct rounding error Thread-Index: AQHRI4+T2KWs1QhTd0qXMTHBhOp3NZ6lauaAgAAfIwCAAAK4AIAABsEAgABISYCAAD7TgIAAAuuA Date: Fri, 20 Nov 2015 23:57:56 +0000 Message-ID: <1448063875.9857.6.camel@intel.com> References: <1448022757-7856-1-git-send-email-prarit@redhat.com> <1448022757-7856-2-git-send-email-prarit@redhat.com> <20151120131833.GD3957@ubuntu> <564F37C8.60307@redhat.com> <20151120151944.GE3957@ubuntu> <564F3FBA.6030806@redhat.com> <1448049757.4914.3.camel@intel.com> <564FB111.5050403@redhat.com> In-Reply-To: <564FB111.5050403@redhat.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.254.182.10] Content-Type: text/plain; charset="utf-8" Content-ID: <9206B1231F401C40B394C65E209C5399@intel.com> MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id tAKNw6mB004766 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. {.n++%ݶw{.n+{G{ayʇڙ,jfhz_(階ݢj"mG?&~iOzv^m ?I