Received: by 2002:a25:e74b:0:0:0:0:0 with SMTP id e72csp936658ybh; Mon, 13 Jul 2020 05:20:21 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwRc1PdmpmY9Qsp6LuTYnRvgGySys1RDh33aty95+enMBnpxPqS2YJC7Tf4IDThmVlw75so X-Received: by 2002:a17:906:2b54:: with SMTP id b20mr73437700ejg.366.1594642820847; Mon, 13 Jul 2020 05:20:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1594642820; cv=none; d=google.com; s=arc-20160816; b=EO3n9JZ7g9KD/jqQP5CgQbxcL0bW88PiT+SD1o0RpDOBbBGQfjvbc4DQwY9lDAiO3Y y6iKOLyLPFPmdPHfYDQjPVrh+frgD4FHoquMhS+XYxpWt/cAcCKrv0WDbIKjh6Jx3SMo hiLH8zRYnN7jtiePKgFCmK6HrwSgttGNXKkUeM5pIsvNMrja0KcwwDsbtawpFlIpknne I3NdynWWDLDK++8xeB6GgX/d0g3sDVPpUNFWOlhvdcM6Ir1zKJfWYKBk+KqttsBVFNB0 tZ3NTg98bRxNc3zEYGc82rW5LZxI6MpxoF48oD6yRC/dshfSAed5T0NvuoSjyegCHCcc yNYQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version; bh=pO75K6jp9I0TgVd5uiJ2Fq8Rt2TkoAscNvbsoxxq4gc=; b=vveBHn30cmO41b4HWlKWtFIxkPuG39oorKSr8vPBX7Ru+7mM1OjkoRNCtIOEBMyphb 8V4uRn/U0uzj1ky5BuRJjNUoEqGarTY+N04NFiLfgN+BBxj1P3ypdNoR3z2ftlmXM1UO HUw9alsUscwoQQBuIuvspzqCBWs4XLJp1N/Y1q2ZC4UpuAsQJTJtyrzYwrT7wqc38V0H Al/CW4edzSs17NkeKbaS42vne47ABHbxYrUQwKa1U0j5w8gxZvVyzCbfy7iHBShYMjQa l+cPrrgfLNpcJi1x2Qyq4CeDJ64B7TG2KOrnR3vdVy0KIzSt4Vy88DWLVlMXFBJ48qjh TQOQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id mf27si9406107ejb.83.2020.07.13.05.19.57; Mon, 13 Jul 2020 05:20:20 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729771AbgGMMQp (ORCPT + 99 others); Mon, 13 Jul 2020 08:16:45 -0400 Received: from mail-ot1-f68.google.com ([209.85.210.68]:44402 "EHLO mail-ot1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726586AbgGMMQo (ORCPT ); Mon, 13 Jul 2020 08:16:44 -0400 Received: by mail-ot1-f68.google.com with SMTP id 5so9296289oty.11; Mon, 13 Jul 2020 05:16:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pO75K6jp9I0TgVd5uiJ2Fq8Rt2TkoAscNvbsoxxq4gc=; b=dPWa6aQZgW7DGcWueb0oDzNGa1E+TbEIvYUXVbCEdclJbzvViyU+bANV1337iivQSx 8lLqLCt7h9X/BPhvZey6kO4jL17Ky1I9XRD1LGUYxTJ7U6gVQRcdlRWBWxFrEetBVoHO bpkCze66VeDJ9CmNmsWqM91+BIpArS84TDeHPMieh5Dq650r4l8HPxHjyplI2LGs/9FS 7c7U9GLYHihG8JX+YXU8VPNSYUgQQcCBF1Y7OgGdZJzcEov9OX32r2VrUosRHQy4yxCH dc2EI6RGNy5ZNqwLLSNJSsJd4hWKvEdquVDANHVvjIFX2Aa8XdlSekHufEXZ37S1MOJI HaFw== X-Gm-Message-State: AOAM532PD7cmMoPfOrUrF5L1ydYM0cNGKeb4Zldk+vHUQwPbiZEQf57L GTLWYc0H6BuLQODq4yB/bVns/kgs6N4kQnSrWok= X-Received: by 2002:a9d:590a:: with SMTP id t10mr33047434oth.262.1594642603476; Mon, 13 Jul 2020 05:16:43 -0700 (PDT) MIME-Version: 1.0 References: <2016232.ihCVsphvri@kreacher> <2988949.NgUrjYMkJj@kreacher> <000801d65634$14f0ecb0$3ed2c610$@net> In-Reply-To: <000801d65634$14f0ecb0$3ed2c610$@net> From: "Rafael J. Wysocki" Date: Mon, 13 Jul 2020 14:16:32 +0200 Message-ID: Subject: Re: [PATCH 2/2] cpufreq: intel_pstate: Use passive mode by default without HWP To: Doug Smythies Cc: "Rafael J. Wysocki" , Srinivas Pandruvada , LKML , "Rafael J. Wysocki" , Viresh Kumar , Giovanni Gherdovich , Linux PM Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jul 9, 2020 at 11:01 PM Doug Smythies wrote: > > Hi Rafael, > > As you may or may not recall, I am attempting to untangle > and separate multiple compounding issues around the > intel_pstate driver and HWP (or not). > > Until everything is figured out, I am using the following rules: > > . never use x86_energy_perf_policy. > . For HWP disabled: never change from active to passive or via versa, but rather do it via boot. > . after boot always check and reset the various power limit log bits that are set. > . never compile the kernel (well, until after any tests), which will set those bits again. > . never run prime95 high heat torture test, which will set those bits again. > . try to never do anything else that will set those bits again. > > On 2020.03.28 05:58 Rafael J. Wysocki wrote: > > > > From: "Rafael J. Wysocki" > > > > After recent changes allowing scale-invariant utilization to be > > used on x86, the schedutil governor on top of intel_pstate in the > > passive mode should be on par with (or better than) the active mode > > "powersave" algorithm of intel_pstate on systems in which > > hardware-managed P-states (HWP) are not used, so it should not be > > necessary to use the internal scaling algorithm in those cases. > > > > Accordingly, modify intel_pstate to start in the passive mode by > > default if the processor at hand does not support HWP of if the driver > > is requested to avoid using HWP through the kernel command line. > > > > Among other things, that will allow utilization clamps and the > > support for RT/DL tasks in the schedutil governor to be utilized on > > systems in which intel_pstate is used. > > > > Signed-off-by: Rafael J. Wysocki > > --- > > Documentation/admin-guide/pm/intel_pstate.rst | 32 ++++++++++++++++----------- > > drivers/cpufreq/intel_pstate.c | 3 ++- > > 2 files changed, 21 insertions(+), 14 deletions(-) > > > > diff --git a/Documentation/admin-guide/pm/intel_pstate.rst b/Documentation/admin- > > guide/pm/intel_pstate.rst > > index ad392f3aee06..39d80bc29ccd 100644 > > --- a/Documentation/admin-guide/pm/intel_pstate.rst > > +++ b/Documentation/admin-guide/pm/intel_pstate.rst > > @@ -62,9 +62,10 @@ on the capabilities of the processor. > > Active Mode > > ----------- > > > > -This is the default operation mode of ``intel_pstate``. If it works in this > > -mode, the ``scaling_driver`` policy attribute in ``sysfs`` for all ``CPUFreq`` > > -policies contains the string "intel_pstate". > > +This is the default operation mode of ``intel_pstate`` for processors with > > +hardware-managed P-states (HWP) support. If it works in this mode, the > > +``scaling_driver`` policy attribute in ``sysfs`` for all ``CPUFreq`` policies > > +contains the string "intel_pstate". > > > > In this mode the driver bypasses the scaling governors layer of ``CPUFreq`` and > > provides its own scaling algorithms for P-state selection. Those algorithms > > @@ -138,12 +139,13 @@ internal P-state selection logic to be less performance-focused. > > Active Mode Without HWP > > ~~~~~~~~~~~~~~~~~~~~~~~ > > > > -This is the default operation mode for processors that do not support the HWP > > -feature. It also is used by default with the ``intel_pstate=no_hwp`` argument > > -in the kernel command line. However, in this mode ``intel_pstate`` may refuse > > -to work with the given processor if it does not recognize it. [Note that > > -``intel_pstate`` will never refuse to work with any processor with the HWP > > -feature enabled.] > > +This operation mode is optional for processors that do not support the HWP > > +feature or when the ``intel_pstate=no_hwp`` argument is passed to the kernel in > > +the command line. The active mode is used in those cases if the > > +``intel_pstate=active`` argument is passed to the kernel in the command line. > > ??? > I can not see anywhere in the code where the kernel command line argument > "intel_pstate=active" is dealt with. My bad, sorry about this. I'll send a patch to fix this issue shortly. Thanks!