Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp3574449imm; Tue, 17 Jul 2018 07:05:04 -0700 (PDT) X-Google-Smtp-Source: AAOMgpeYBpxRocpA+30CY50I0wVnTUAatJdh3Z5n42CWjKhzeFroCNjdWvHILRU52LUWRu6Mgtsa X-Received: by 2002:a17:902:5381:: with SMTP id c1-v6mr1757032pli.137.1531836304763; Tue, 17 Jul 2018 07:05:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1531836304; cv=none; d=google.com; s=arc-20160816; b=Ej3gOTt4JOBKwxjTgsFECq/0F6n9OoLOl9KM1lwMCIotZCcTiYqS6oX0KX2y9pmtT0 vOzR+eH4hBLN5PkGDnZKnhFR2lVasnJ7AeosiCJOtifbkaKjpk5PKtP5QQ8GClDWR8ED 4PHXQKQ5IRervkrsU5dQwsB/VmkooMOknuMCF1KPSQ2tLmc72cvmYSo60PjwuBR6iDIi y7u2wmXPAAZs3uHbGYy884RN8ywzj3qMhBvf3PovAFmBh1JK5GSgbLYK6fmLopRkcna2 ZiyGnvlPkmfbRRTLJMZvvNwrH4KHim8jA8I5yuWuFS2I72vmONsUh13fPN5Zl2NwRKK3 7NdQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=2GrnN5Yod0apVL4iD/E31PaXO8S34xUrg5tlo6NSj+4=; b=Kd+1IvlqnqMvRpadeWHbVzcRDK3E9oB7lvFtUa4MmMWwz8vwCpUpofVeyK4jksEZQu UjrnJkn/XquPCsetcOyFP3+M1NJCpqsrgTonCeKF2TTtTMTK6QG1bd4TO5hTeouDGnKE 49walbJRc80GXHBFUuc6lPUV6ux5/mvBEPnwkghvpS9B3QUoU8qBeaGaSVl/L+WpzU+A w5kPQKukCgEx+Ege8qltT6iy8I2qDIAahGCtKA/Tx6B871VhH6XOeuDD0Ul0t7EhWcSQ yLj9hRBRPtnzhOddD7aji7sDQrQofobXlP9eDy8k8BrVKJBAIbp1jdNy03mSa83o8Zmj 2gqg== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b135-v6si1016304pga.51.2018.07.17.07.04.49; Tue, 17 Jul 2018 07:05:04 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731703AbeGQOgu (ORCPT + 99 others); Tue, 17 Jul 2018 10:36:50 -0400 Received: from smtp.nue.novell.com ([195.135.221.5]:45986 "EHLO smtp.nue.novell.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729035AbeGQOgu (ORCPT ); Tue, 17 Jul 2018 10:36:50 -0400 Received: from emea4-mta.ukb.novell.com ([10.120.13.87]) by smtp.nue.novell.com with ESMTP (TLS encrypted); Tue, 17 Jul 2018 16:03:59 +0200 Received: from suselix (nwb-a10-snat.microfocus.com [10.120.13.202]) by emea4-mta.ukb.novell.com with ESMTP (TLS encrypted); Tue, 17 Jul 2018 15:03:38 +0100 Date: Tue, 17 Jul 2018 16:03:36 +0200 From: Andreas Herrmann To: "Rafael J. Wysocki" Cc: "Rafael J. Wysocki" , Peter Zijlstra , Frederic Weisbecker , Viresh Kumar , Linux PM , Linux Kernel Mailing List Subject: Re: Commit 554c8aa8ecad causing severe performance degression with pcc-cpufreq Message-ID: <20180717140336.ayovaz4ksdlak6bb@suselix> References: <20180717065048.74mmgk4t5utjaa6a@suselix> <20180717092721.onkaf3qsu7te6syi@suselix> <20180717093620.ym6phfmr3rfvsxyo@suselix> <3724084.DyflrVPzDS@aspire.rjw.lan> <20180717102136.snayvzmv2h3dcwiq@suselix> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20180717102136.snayvzmv2h3dcwiq@suselix> User-Agent: NeoMutt/20170421 (1.8.2) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jul 17, 2018 at 12:21:36PM +0200, Andreas Herrmann wrote: > On Tue, Jul 17, 2018 at 12:09:21PM +0200, Rafael J. Wysocki wrote: ---8<--- > > OK, the patch is below. > > > > First, I hope that if "Collaborative Power Control" is disabled, it will > > simply hide the PCCH object and so intel_pstate will still not load then. > > PCCH is hidden in that case. > > > The main question basically is what the OS is expected to do if > > "Dynamic Power Savings Mode" is set. If we are *expected* to use > > the PCC interface then, intel_pstate may not work in that case, but > > I suspect that the PCC interface allows extra energy to be saved > > over what is possible without it. > > I'll test it and see what happens. I've tested it on top of v4.18-rc5-36-g30b06abfb92b. intel_pstate now loads instead of pcc-cpufreq and system looks stable. When disabling "Collaborative Power Control" no cpufreq driver is loaded (as expected). Performance (with kernbench) is as expected (always better than any brew of pcc-cpufreq + misc modifications to this driver + partial rollback of commit 554c8aa8ecad). If you like you can add either Tested-by or Reviewed-by: Andreas Herrmann I think this patch should be tagged for 4.17-stable. Thanks, Andreas > > --- > > drivers/cpufreq/intel_pstate.c | 17 ++++++++++++++++- > > 1 file changed, 16 insertions(+), 1 deletion(-) > > > > Index: linux-pm/drivers/cpufreq/intel_pstate.c > > =================================================================== > > --- linux-pm.orig/drivers/cpufreq/intel_pstate.c > > +++ linux-pm/drivers/cpufreq/intel_pstate.c > > @@ -2391,6 +2391,18 @@ static bool __init intel_pstate_no_acpi_ > > return true; > > } > > > > +static bool __init intel_pstate_no_acpi_pcch(void) > > +{ > > + acpi_status status; > > + acpi_handle handle; > > + > > + status = acpi_get_handle(NULL, "\\_SB", &handle); > > + if (ACPI_FAILURE(status)) > > + return true; > > + > > + return !acpi_has_method(handle, "PCCH"); > > +} > > + > > static bool __init intel_pstate_has_acpi_ppc(void) > > { > > int i; > > @@ -2450,7 +2462,10 @@ static bool __init intel_pstate_platform > > > > switch (plat_info[idx].data) { > > case PSS: > > - return intel_pstate_no_acpi_pss(); > > + if (!intel_pstate_no_acpi_pss()) > > + return false; > > + > > + return intel_pstate_no_acpi_pcch(); > > case PPC: > > return intel_pstate_has_acpi_ppc() && !force_load; > > } > > > >