From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED,USER_AGENT_NEOMUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A7A83ECDFB1 for ; Tue, 17 Jul 2018 09:36:30 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 6B50020C0E for ; Tue, 17 Jul 2018 09:36:30 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6B50020C0E Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730421AbeGQKIK (ORCPT ); Tue, 17 Jul 2018 06:08:10 -0400 Received: from smtp.nue.novell.com ([195.135.221.5]:40329 "EHLO smtp.nue.novell.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728835AbeGQKIK (ORCPT ); Tue, 17 Jul 2018 06:08:10 -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 11:36:25 +0200 Received: from suselix (nwb-a10-snat.microfocus.com [10.120.13.201]) by emea4-mta.ukb.novell.com with ESMTP (TLS encrypted); Tue, 17 Jul 2018 10:36:23 +0100 Date: Tue, 17 Jul 2018 11:36:20 +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: <20180717093620.ym6phfmr3rfvsxyo@suselix> References: <20180717065048.74mmgk4t5utjaa6a@suselix> <20180717085039.kqxwbkgruhj5qxtx@suselix> <20180717091152.l4ixicbp6imvqtsr@suselix> <20180717092721.onkaf3qsu7te6syi@suselix> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20180717092721.onkaf3qsu7te6syi@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 11:27:21AM +0200, Andreas Herrmann wrote: > On Tue, Jul 17, 2018 at 11:23:25AM +0200, Rafael J. Wysocki wrote: > > On Tue, Jul 17, 2018 at 11:11 AM, Andreas Herrmann wrote: > > > On Tue, Jul 17, 2018 at 11:06:29AM +0200, Rafael J. Wysocki wrote: > > >> On Tue, Jul 17, 2018 at 10:50 AM, Andreas Herrmann wrote: > > >> > > >> [cut] > > >> > > >> > > > >> > On balance before this commit users could use pcc-cpufreq but had > > >> > already suboptimal performance (compared to say intel_pstate driver > > >> > which can be used changing BIOS options). > > >> > > >> BTW, I wonder why you need to change the BIOS options for intel_pstate to load. > > > > > > I think this is because of (in intel_pstate_init()): > > > > > > /* > > > * The Intel pstate driver will be ignored if the platform > > > * firmware has its own power management modes. > > > */ > > > if (intel_pstate_platform_pwr_mgmt_exists()) > > > return -ENODEV; > > > > > > > OK, because of the "Proliant" entry, right? > > > > So it looks like we have an issue there. We find the entry and we > > look for _PSS. It is not there, so we assume that the firmware is > > expected to control performance, which is not the case. FYI, there is another BIOS setting on those systems. It's called "Collaborative Power Control" (AFAIK enabled by default). Only if this is disabled, firmware is (alone) in control of performance. (And of course in this case neither pcc-cpufreq nor intel_pstate will be loaded). > > It looks like we also should look for the presence of the PCC > > interface in there. > > > > I can provide a patch for that, will you be able to test it? > > Yes, I can test it. > > > >> It should be initialized before pcc-cpufreq (according to their > > >> respective initcall levels), so in theory intel_pstate should be used > > >> by default on the affected systems anyway. > > > > > >> What BIOS settings need to be changed for that? > > > > > > Already answered in other mail. > > > > Indeed. > > > Andreas >