Received: by 2002:a05:6a10:6744:0:0:0:0 with SMTP id w4csp312159pxu; Fri, 23 Oct 2020 01:03:42 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyDnkDJ7MQdyKbMdZlmMdCcbyzCZk/gaHLXWfWxARweMJLTi/pmxS64KnJZsrmhZazJuFdg X-Received: by 2002:a17:906:b110:: with SMTP id u16mr808934ejy.55.1603440222107; Fri, 23 Oct 2020 01:03:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1603440222; cv=none; d=google.com; s=arc-20160816; b=VFpimYY8kbQ4b8eMyzSafQxTsWJpQcnr0JPMFsICzH6N944ZoCO7i0V/K7saxHmxEr /elJ5NzHryOa4+1xzt6v3q5/Aw1i22FGnn3ex0jgTTWAF6uTKHFxtC+eYD3o3ZDHmAA6 4Y0RZ4AeS+6VFfxO17moWoxBec7QoH8MZLXiTE645Im064PXRzuIHwAkGXMaInXIF3gu 8oEyDr1ZWUq1ex8pbLctFOTVMTPYxTYOeZcTwaoP0sNci9mgiKxK06dRjyWeei8sgNmm olIjxy2xsn9RLcU3CUeBOUc1EChWfikPKkKdsWV0rE0Xf7T1ImSnJRt5SbD0PCR66wbf +9WQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=qZx9FbWhVPPPhazjV3moDfr24pwj93WkkmuXXCaHCHA=; b=kYhmBZ4CrAnKYETjiPQ8bdeH3Nkn+Clu4OGNe8fdcC4jvOV+QbWQS2j0oIS5bOKohT pketY500tjrVcf+CRmLgypVoyCff6LTMyDPH7rUpZRxyhW6Uw3qViOQ4RfVpXImv++6P Q473RBQezWtPyPgruN1GAJuHHXCsDzMMqIVTA08YSFQgSYxYrjXX1Af4287UbqlpGHON 1BHZesMyHJgZrjx2MpTLyEJP/wURGplQ1kc7UJ+aJtHzJ6wO7ECKR6I4bIyWJBKcPj7R dnPwHzFubeKwM8+2dVppYwHLbFrt/kuYH0HFUgeDkfHRvJtYGiIx2SMQHBI4koG4N5bp vEjQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=B64hrugZ; 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=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id d1si352612ejh.43.2020.10.23.01.03.19; Fri, 23 Oct 2020 01:03:42 -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; dkim=pass header.i=@linaro.org header.s=google header.b=B64hrugZ; 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=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S372357AbgJWGRI (ORCPT + 99 others); Fri, 23 Oct 2020 02:17:08 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37994 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S372337AbgJWGRI (ORCPT ); Fri, 23 Oct 2020 02:17:08 -0400 Received: from mail-pl1-x641.google.com (mail-pl1-x641.google.com [IPv6:2607:f8b0:4864:20::641]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AA794C0613D4 for ; Thu, 22 Oct 2020 23:17:06 -0700 (PDT) Received: by mail-pl1-x641.google.com with SMTP id t4so298276plq.13 for ; Thu, 22 Oct 2020 23:17:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=qZx9FbWhVPPPhazjV3moDfr24pwj93WkkmuXXCaHCHA=; b=B64hrugZLYwFDebwJ2n7cVm7IRpj+T6U2GvjbXeupsrBGTGAYwZLtGRoMLjXS0LCNS Nmo2U523Hv+ktz4L2Otq4L86ZqOFYu3WLlrAGgpC49UpMaaAYNxmetjkWeXqk0jiSIla gY5Ho3k8QylY8TFUS5YT3M6B9u2h4iyXMgZXERvFgGVAcRiT1CaboY4C/hVO8V4atbq6 rPURegBP7LxCH+Yr4d4x1Qa7LALmduuR2heeao1YguWmBHEJ87V3XyUSsA2jJopT9x3d rQLsbWY1PBXHXcJEfEf4Mrc4huuq4akMabCdSsVJtGm8Kgp+4t+qR6lvCa8qqXL9hsz+ nLvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=qZx9FbWhVPPPhazjV3moDfr24pwj93WkkmuXXCaHCHA=; b=L/jCxruLSjpNBTrfkigyiTpnuVx8WlBFw90Ysx4ObfDqIDfXymJoFhAMqKzXT4xTd/ pxyz11bP6rHJDRymnytVz9WGzd6jorNf+OFHPthRq1PRx7D96a8EZ9ksyamGL0bgZ8VY eDpSbrS0yRFh7wIg22H3XnnyWcWfciD8BNUkfF037kRHWJ70Vb4DvXd6iUE1lrropRcy UpfyPt3HlciF6tWokDkUnwz4b1Ilg8y1UwLYBJA1CXbUSnpwbjPk/PitWJI+SMCTYuYK 2Kl+b4qoMX8wZnvQHyzF1YOm0F7baJx1A+O5pozpqraqQ7be7G2ikApqjVAdjz01BJjg PHOA== X-Gm-Message-State: AOAM532I/eJfL2dyZygMJ7R1b0vYxaCmklN+vFVsprybJ0WjqEatsto4 p4prwaqWM8Ub0qFiIBLThL2fYw== X-Received: by 2002:a17:902:6b45:b029:d3:df34:3222 with SMTP id g5-20020a1709026b45b02900d3df343222mr874550plt.68.1603433825974; Thu, 22 Oct 2020 23:17:05 -0700 (PDT) Received: from localhost ([122.181.54.133]) by smtp.gmail.com with ESMTPSA id lb13sm600802pjb.5.2020.10.22.23.17.04 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 22 Oct 2020 23:17:05 -0700 (PDT) Date: Fri, 23 Oct 2020 11:47:03 +0530 From: Viresh Kumar To: "Rafael J. Wysocki" Cc: Peter Zijlstra , Julia Lawall , Mel Gorman , Ingo Molnar , kernel-janitors@vger.kernel.org, Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Daniel Bristot de Oliveira , linux-kernel@vger.kernel.org, Valentin Schneider , Gilles Muller , srinivas.pandruvada@linux.intel.com, Linux PM , Len Brown Subject: Re: [PATCH] cpufreq: Avoid configuring old governors as default with intel_pstate Message-ID: <20201023061703.jjpmoeq7wzwqtsid@vireshk-i7> References: <1603211879-1064-1-git-send-email-Julia.Lawall@inria.fr> <34115486.YmRjPRKJaA@kreacher> <20201022120213.GG2611@hirez.programming.kicks-ass.net> <8312288.dAKoTdFk2S@kreacher> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8312288.dAKoTdFk2S@kreacher> User-Agent: NeoMutt/20180716-391-311a52 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 22-10-20, 18:23, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > Subject: [PATCH] cpufreq: Avoid configuring old governors as default with intel_pstate > > Commit 33aa46f252c7 ("cpufreq: intel_pstate: Use passive mode by > default without HWP") was meant to cause intel_pstate without HWP > to be used in the passive mode with the schedutil governor on top of > it by default, but it missed the case in which either "ondemand" or > "conservative" was selected as the default governor in the existing > kernel config, in which case the previous old governor configuration > would be used, causing the default legacy governor to be used on top > of intel_pstate instead of schedutil. > > Address this by preventing "ondemand" and "conservative" from being > configured as the default cpufreq governor in the case when schedutil > is the default choice for the default governor setting. > > [Note that the default cpufreq governor can still be set via the > kernel command line if need be and that choice is not limited, > so if anyone really wants to use one of the legacy governors by > default, it can be achieved this way.] > > Fixes: 33aa46f252c7 ("cpufreq: intel_pstate: Use passive mode by default without HWP") > Cc: 5.8+ # 5.8+ > Signed-off-by: Rafael J. Wysocki > --- > drivers/cpufreq/Kconfig | 2 ++ > 1 file changed, 2 insertions(+) > > Index: linux-pm/drivers/cpufreq/Kconfig > =================================================================== > --- linux-pm.orig/drivers/cpufreq/Kconfig > +++ linux-pm/drivers/cpufreq/Kconfig > @@ -71,6 +71,7 @@ config CPU_FREQ_DEFAULT_GOV_USERSPACE > > config CPU_FREQ_DEFAULT_GOV_ONDEMAND > bool "ondemand" > + depends on !SMP || !X86_INTEL_PSTATE > select CPU_FREQ_GOV_ONDEMAND > select CPU_FREQ_GOV_PERFORMANCE > help > @@ -83,6 +84,7 @@ config CPU_FREQ_DEFAULT_GOV_ONDEMAND > > config CPU_FREQ_DEFAULT_GOV_CONSERVATIVE > bool "conservative" > + depends on !SMP || !X86_INTEL_PSTATE While reading this first it felt like a SMP platforms related problem (which I was surprised about), and then I understood what you are doing. I wonder if rewriting it this way makes it more readable with same result eventually. depends on !(X86_INTEL_PSTATE && SMP) -- viresh