Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp1505897imm; Tue, 15 May 2018 21:52:18 -0700 (PDT) X-Google-Smtp-Source: AB8JxZrgboOdacpAGxdPCFjwUJFBYbfULaes8gh9BgAVMYigKauUhbme6WbR5Ov8wwiXXN37MXuq X-Received: by 2002:a63:4143:: with SMTP id o64-v6mr9312957pga.280.1526446338452; Tue, 15 May 2018 21:52:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1526446338; cv=none; d=google.com; s=arc-20160816; b=z4nA45sDVl6pCRUiXMUFeYxacfhWkQE8wevcEs8/g1rNBbJGm/DgR7lKWTpVQmklFU 64JPO1qHavR5sX6W4OGCgcxnz9XsKGmtUR+r3NsGS7/M7FoiBbQBuy33daHvFlWUHe2M 8TQ6PazAHQhMN+drKVBIi/86eSip5iId2O3dbem6TOYTXqQesHEH7Q6rtHZzVCgF8LgA KlLVW+3/KUUrVFASyc0D0HEzunfjGROTfGi87S0zZoSmmzaGC40i/LtTVxqNiDuPjMjw 4MPk1NldA9B2dKmBi6g05N92yuJREWZiE0KSGD50KNyXilye7spetuO+z0BiZLET3UjD /yBQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from:arc-authentication-results; bh=rdprePRchBuPtHVRlXigMTpwHmzzSKThmPieSJQ2GHk=; b=PdijsmY9ltufQr869EgB4pEPentHwuRsN7Yl5nYV2jJB7oCVkDbMheKPDJ0KkfCV29 Dc0pxjvIav5IE+5+aKZzL7PPS1ppnV1f+fwUr8hf3pNk7iXPCJixEm1CpTD4/SL0baO9 RBt5eN5XCyixL/q6cHYuCBqkL1JNaDukldaXT/XS1S1xg8pBzB94gGqWZQb2Pab0nCWX Aek/9wyjn0IYohp12QIg6O4fAFye35b+KtPiw8ocpw7IZjnxIM4YiaWCFXxTMVsqJ598 +GjSMaWtisWYnbS9tf+Wg4Ygbhf4Dbl9EUtwJdfHyoWGAzx6qWVJz1CrmNcl6HnJuoKK FULg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f5-v6si1793055pfb.314.2018.05.15.21.52.04; Tue, 15 May 2018 21:52:18 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752443AbeEPEuS (ORCPT + 99 others); Wed, 16 May 2018 00:50:18 -0400 Received: from mga04.intel.com ([192.55.52.120]:1168 "EHLO mga04.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751671AbeEPEtV (ORCPT ); Wed, 16 May 2018 00:49:21 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga007.jf.intel.com ([10.7.209.58]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 May 2018 21:49:19 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.49,404,1520924400"; d="scan'208";a="41300349" Received: from sunandaa-mobl.amr.corp.intel.com (HELO spandruv-mobl.jf.intel.com) ([10.252.135.192]) by orsmga007.jf.intel.com with ESMTP; 15 May 2018 21:49:19 -0700 From: Srinivas Pandruvada To: srinivas.pandruvada@linux.intel.com, tglx@linutronix.de, mingo@redhat.com, peterz@infradead.org, bp@suse.de, lenb@kernel.org, rjw@rjwysocki.net, mgorman@techsingularity.net Cc: x86@kernel.org, linux-pm@vger.kernel.org, viresh.kumar@linaro.org, juri.lelli@arm.com, linux-kernel@vger.kernel.org Subject: [RFC/RFT] [PATCH 07/10] cpufreq: intel_pstate: HWP boost performance on busy task migrate Date: Tue, 15 May 2018 21:49:08 -0700 Message-Id: <20180516044911.28797-8-srinivas.pandruvada@linux.intel.com> X-Mailer: git-send-email 2.9.5 In-Reply-To: <20180516044911.28797-1-srinivas.pandruvada@linux.intel.com> References: <20180516044911.28797-1-srinivas.pandruvada@linux.intel.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org When a busy task migrates to a new CPU boost HWP prformance to max. This helps workloads on servers with per core P-states, which saturates all CPUs and then they migrate frequently. But changing limits has extra over head of issuing new HWP Request MSR, which takes 1000+ cycles. So this change limits setting HWP Request MSR. Rate control in setting HWP Requests: - If the current performance is around P1, simply ignore. - Once set wait till hold time, till remove boost. While the boost is on, another flags is notified, it will prolong boost. - The task migrates needs to have some utilzation which is more than threshold utilization, which will trigger P-state above minimum. Signed-off-by: Srinivas Pandruvada --- drivers/cpufreq/intel_pstate.c | 37 ++++++++++++++++++++++++++++++++++++- 1 file changed, 36 insertions(+), 1 deletion(-) diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c index d418265..ec455af 100644 --- a/drivers/cpufreq/intel_pstate.c +++ b/drivers/cpufreq/intel_pstate.c @@ -227,6 +227,7 @@ struct global_params { * defines callback and arguments * @hwp_boost_active: HWP performance is boosted on this CPU * @last_io_update: Last time when IO wake flag was set + * @migrate_hint: Set when scheduler indicates thread migration * * This structure stores per CPU instance data for all CPUs. */ @@ -263,6 +264,7 @@ struct cpudata { call_single_data_t csd; bool hwp_boost_active; u64 last_io_update; + bool migrate_hint; }; static struct cpudata **all_cpu_data; @@ -1438,6 +1440,8 @@ static int hwp_boost_hold_time_ms = 3; #define BOOST_PSTATE_THRESHOLD (SCHED_CAPACITY_SCALE / 2) static int hwp_boost_pstate_threshold = BOOST_PSTATE_THRESHOLD; +static int hwp_boost_threshold_busy_pct; + static inline bool intel_pstate_check_boost_threhold(struct cpudata *cpu) { /* @@ -1450,12 +1454,32 @@ static inline bool intel_pstate_check_boost_threhold(struct cpudata *cpu) return true; } +static inline int intel_pstate_get_sched_util(struct cpudata *cpu) +{ + unsigned long util_cfs, util_dl, max, util; + + cpufreq_get_sched_util(cpu->cpu, &util_cfs, &util_dl, &max); + util = min(util_cfs + util_dl, max); + return util * 100 / max; +} + static inline void intel_pstate_update_util_hwp(struct update_util_data *data, u64 time, unsigned int flags) { struct cpudata *cpu = container_of(data, struct cpudata, update_util); - if (flags & SCHED_CPUFREQ_IOWAIT) { + if (flags & SCHED_CPUFREQ_MIGRATION) { + if (intel_pstate_check_boost_threhold(cpu)) + cpu->migrate_hint = true; + + cpu->last_update = time; + /* + * The rq utilization data is not migrated yet to the new CPU + * rq, so wait for call on local CPU to boost. + */ + if (smp_processor_id() != cpu->cpu) + return; + } else if (flags & SCHED_CPUFREQ_IOWAIT) { /* * Set iowait_boost flag and update time. Since IO WAIT flag * is set all the time, we can't just conclude that there is @@ -1499,6 +1523,17 @@ static inline void intel_pstate_update_util_hwp(struct update_util_data *data, intel_pstate_hwp_boost_up(cpu); else smp_call_function_single_async(cpu->cpu, &cpu->csd); + return; + } + + /* Ignore if the migrated thread has low utilization */ + if (cpu->migrate_hint && smp_processor_id() == cpu->cpu) { + int util = intel_pstate_get_sched_util(cpu); + + if (util >= hwp_boost_threshold_busy_pct) { + cpu->hwp_boost_active = true; + intel_pstate_hwp_boost_up(cpu); + } } } -- 2.9.5