From patchwork Fri Nov 16 22:24:19 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: srinivas pandruvada X-Patchwork-Id: 10687097 X-Patchwork-Delegate: rjw@sisk.pl Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 7C67613B5 for ; Fri, 16 Nov 2018 22:24:46 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 6B5212D88E for ; Fri, 16 Nov 2018 22:24:46 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 5FB842D897; Fri, 16 Nov 2018 22:24:46 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.9 required=2.0 tests=BAYES_00,MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id DBD6E2D88E for ; Fri, 16 Nov 2018 22:24:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728110AbeKQIiu (ORCPT ); Sat, 17 Nov 2018 03:38:50 -0500 Received: from mga18.intel.com ([134.134.136.126]:20405 "EHLO mga18.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725911AbeKQIiu (ORCPT ); Sat, 17 Nov 2018 03:38:50 -0500 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga106.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Nov 2018 14:24:36 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.56,241,1539673200"; d="scan'208";a="96936487" Received: from spandruv-desk.jf.intel.com ([10.54.75.31]) by FMSMGA003.fm.intel.com with ESMTP; 16 Nov 2018 14:24:36 -0800 From: Srinivas Pandruvada To: lenb@kernel.org, rjw@rjwysocki.net, viresh.kumar@linaro.org, corbet@lwn.net Cc: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, yu.c.chen@intel.com, Srinivas Pandruvada Subject: [PATCH 1/2] cpufreq: intel_pstate: Force HWP min perf before offline Date: Fri, 16 Nov 2018 14:24:19 -0800 Message-Id: <20181116222420.24260-1-srinivas.pandruvada@linux.intel.com> X-Mailer: git-send-email 2.17.1 Sender: linux-pm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Force HWP Request MAX = HWP Request MIN = HWP Capability MIN and EPP to 0xFF. In this way the performance limits on the offlined CPU will not influence performance limits on its sibling CPU, which is still online. If the sibling CPU is calling for higher performance, it will impact the max core performance. Here core performance will follow higher of the performance requests from each sibling. Reported-and-tested-by: Chen Yu Signed-off-by: Srinivas Pandruvada --- drivers/cpufreq/intel_pstate.c | 28 ++++++++++++++++++++++++++-- 1 file changed, 26 insertions(+), 2 deletions(-) diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c index 14f551a3d36e..501ab9f4489a 100644 --- a/drivers/cpufreq/intel_pstate.c +++ b/drivers/cpufreq/intel_pstate.c @@ -830,6 +830,28 @@ static void intel_pstate_hwp_set(unsigned int cpu) wrmsrl_on_cpu(cpu, MSR_HWP_REQUEST, value); } +static void intel_pstate_hwp_force_min_perf(int cpu) +{ + u64 value; + int min_perf; + + value = all_cpu_data[cpu]->hwp_req_cached; + value &= ~GENMASK_ULL(31, 0); + min_perf = HWP_LOWEST_PERF(all_cpu_data[cpu]->hwp_cap_cached); + + /* Set hwp_max = hwp_min */ + value |= HWP_MAX_PERF(min_perf); + value |= HWP_MIN_PERF(min_perf); + + /* Set EPP/EPB to min */ + if (static_cpu_has(X86_FEATURE_HWP_EPP)) + value |= HWP_ENERGY_PERF_PREFERENCE(HWP_EPP_POWERSAVE); + else + intel_pstate_set_epb(cpu, HWP_EPP_BALANCE_POWERSAVE); + + wrmsrl_on_cpu(cpu, MSR_HWP_REQUEST, value); +} + static int intel_pstate_hwp_save_state(struct cpufreq_policy *policy) { struct cpudata *cpu_data = all_cpu_data[policy->cpu]; @@ -2093,10 +2115,12 @@ static void intel_pstate_stop_cpu(struct cpufreq_policy *policy) pr_debug("CPU %d exiting\n", policy->cpu); intel_pstate_clear_update_util_hook(policy->cpu); - if (hwp_active) + if (hwp_active) { intel_pstate_hwp_save_state(policy); - else + intel_pstate_hwp_force_min_perf(policy->cpu); + } else { intel_cpufreq_stop_cpu(policy); + } } static int intel_pstate_cpu_exit(struct cpufreq_policy *policy) From patchwork Fri Nov 16 22:24:20 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: srinivas pandruvada X-Patchwork-Id: 10687095 X-Patchwork-Delegate: rjw@sisk.pl Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 3B6BB14D6 for ; Fri, 16 Nov 2018 22:24:46 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 2AE0A2D891 for ; Fri, 16 Nov 2018 22:24:46 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 1F16A2D89A; Fri, 16 Nov 2018 22:24:46 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.9 required=2.0 tests=BAYES_00,MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id B9FFC2D897 for ; Fri, 16 Nov 2018 22:24:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726040AbeKQIiu (ORCPT ); Sat, 17 Nov 2018 03:38:50 -0500 Received: from mga18.intel.com ([134.134.136.126]:20405 "EHLO mga18.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725819AbeKQIiu (ORCPT ); Sat, 17 Nov 2018 03:38:50 -0500 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga106.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Nov 2018 14:24:37 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.56,241,1539673200"; d="scan'208";a="96936490" Received: from spandruv-desk.jf.intel.com ([10.54.75.31]) by FMSMGA003.fm.intel.com with ESMTP; 16 Nov 2018 14:24:37 -0800 From: Srinivas Pandruvada To: lenb@kernel.org, rjw@rjwysocki.net, viresh.kumar@linaro.org, corbet@lwn.net Cc: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, yu.c.chen@intel.com, Srinivas Pandruvada Subject: [PATCH 2/2] Documentation: intel_pstate: Clarify coordination of P-State limits Date: Fri, 16 Nov 2018 14:24:20 -0800 Message-Id: <20181116222420.24260-2-srinivas.pandruvada@linux.intel.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20181116222420.24260-1-srinivas.pandruvada@linux.intel.com> References: <20181116222420.24260-1-srinivas.pandruvada@linux.intel.com> Sender: linux-pm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Explain influence of per-core P-states and hyper threading on the effective performance. Signed-off-by: Srinivas Pandruvada --- Documentation/admin-guide/pm/intel_pstate.rst | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/Documentation/admin-guide/pm/intel_pstate.rst b/Documentation/admin-guide/pm/intel_pstate.rst index ac6f5c597a56..ec0f7c111f65 100644 --- a/Documentation/admin-guide/pm/intel_pstate.rst +++ b/Documentation/admin-guide/pm/intel_pstate.rst @@ -495,7 +495,15 @@ on the following rules, regardless of the current operation mode of the driver: 2. Each individual CPU is affected by its own per-policy limits (that is, it cannot be requested to run faster than its own per-policy maximum and it - cannot be requested to run slower than its own per-policy minimum). + cannot be requested to run slower than its own per-policy minimum). The + effective performance depends on whether the platform supports per core + P-states, hyper-threading is enabled and on current performance requests + from other CPUs. When platform doesn't support per core P-states, the + effective performance can be more than the policy limits set on a CPU, if + other CPUs are requesting higher performance at that moment. Even with per + core P-states support, when hyper-threading is enabled, if the sibling CPU + is requesting higher performance, the other siblings will get higher + performance than their policy limits. 3. The global and per-policy limits can be set independently.