Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751801AbdCSNlU (ORCPT ); Sun, 19 Mar 2017 09:41:20 -0400 Received: from cloudserver094114.home.net.pl ([79.96.170.134]:55501 "EHLO cloudserver094114.home.net.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751464AbdCSNlQ (ORCPT ); Sun, 19 Mar 2017 09:41:16 -0400 From: "Rafael J. Wysocki" To: Linux PM Cc: LKML , Peter Zijlstra , Srinivas Pandruvada , Viresh Kumar , Juri Lelli , Vincent Guittot , Patrick Bellasi , Joel Fernandes , Morten Rasmussen , Ingo Molnar Subject: [PATCH 0/2] cpufreq: schedutil: Fix and optimization Date: Sun, 19 Mar 2017 14:21:21 +0100 Message-ID: <4366682.tsferJN35u@aspire.rjw.lan> User-Agent: KMail/4.14.10 (Linux/4.10.0+; KDE/4.14.9; x86_64; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 856 Lines: 21 Hi, Patch [1/2] in this series fixes an initialization issue in schedutil. Patch [2/2] is an optimization, but it also might be regarded as a fix or at least a problem workaround. Namely, while playing with the passive mode in intel_pstate lately I noticed that schedutil evidently underestimated CPU utilization at high loads. I guess it has been known for a while, but this is the first time I've seen that so clearly (actually by looking at the values written to the P-state request register and not via frequencies). After some investigation I can quite confidently attribute that to a PELT metric issue, as everything else has been ruled out with high confidence, and hence the patch (which also works around the problem adding even more condifence to the observation that PELT underestimates CPU utilization at least sometimes). Thanks, Rafael