linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <rjw@rjwysocki.net>
To: x86 <x86@kernel.org>
Cc: Linux PM <linux-pm@vger.kernel.org>,
	Ido Schimmel <idosch@idosch.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Len Brown <len.brown@intel.com>,
	Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>,
	Laura Abbott <labbott@fedoraproject.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@kernel.org>,
	Simon Schricker <sschricker@suse.de>,
	Borislav Petkov <bp@suse.de>, Hannes Reinecke <hare@suse.de>
Subject: [PATCH] x86: intel_epb: Do not build when CONFIG_PM is unset
Date: Mon, 27 May 2019 12:56:07 +0200	[thread overview]
Message-ID: <3844875.YPkTDDlcrF@kreacher> (raw)
In-Reply-To: <20190509174338.GA24432@splinter>

From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

Commit 9ed0985332a6 ("x86: intel_epb: Take CONFIG_PM into account")
prevented the majority of the Performance and Energy Bias Hint (EPB)
handling code from being built when CONFIG_PM is unset to fix a
regression introduced by commit b9c273babce7 ("PM / arch: x86:
MSR_IA32_ENERGY_PERF_BIAS sysfs interface").

In hindsight, however, it would be better to skip all of the EPB
handling code for CONFIG_PM unset as there really is no reason for
it to be there in that case.  Namely, if the EPB is not touched
by the kernel at all with CONFIG_PM unset, there is no need to
worry about modifying the EPB inadvertently on CPU online and since
the system will not suspend or hibernate then, there is no need to
worry about possible modifications of the EPB by the platform
firmware during system-wide PM transitions.

For this reason, revert the changes made by commit 9ed0985332a6
and only allow intel_epb.o to be built when CONFIG_PM is set.

Note that this changes the behavior of the kernels built with
CONFIG_PM unset as they will not modify the EPB on boot if it is
zero initially any more, so it is not a fix strictly speaking, but
users building their kernels with CONFIG_PM unset really should not
expect them to take energy efficiency into account.  Moreover, if
CONFIG_PM is unset for performance reasons, leaving EPB as set
initially by the platform firmware will actually be consistent
with the user's expectations.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---

This is complementary to the EPB handling changes made in the current
development cycle, so IMO it would be good to do it in this cycle too
if there are no technical concerns or objections regarding it.

---
 arch/x86/kernel/cpu/Makefile    |    5 ++++-
 arch/x86/kernel/cpu/intel_epb.c |   22 +---------------------
 2 files changed, 5 insertions(+), 22 deletions(-)

Index: linux-pm/arch/x86/kernel/cpu/Makefile
===================================================================
--- linux-pm.orig/arch/x86/kernel/cpu/Makefile
+++ linux-pm/arch/x86/kernel/cpu/Makefile
@@ -28,7 +28,10 @@ obj-y			+= cpuid-deps.o
 obj-$(CONFIG_PROC_FS)	+= proc.o
 obj-$(CONFIG_X86_FEATURE_NAMES) += capflags.o powerflags.o
 
-obj-$(CONFIG_CPU_SUP_INTEL)		+= intel.o intel_pconfig.o intel_epb.o
+ifdef CONFIG_CPU_SUP_INTEL
+obj-y			+= intel.o intel_pconfig.o
+obj-$(CONFIG_PM)	+= intel_epb.o
+endif
 obj-$(CONFIG_CPU_SUP_AMD)		+= amd.o
 obj-$(CONFIG_CPU_SUP_HYGON)		+= hygon.o
 obj-$(CONFIG_CPU_SUP_CYRIX_32)		+= cyrix.o
Index: linux-pm/arch/x86/kernel/cpu/intel_epb.c
===================================================================
--- linux-pm.orig/arch/x86/kernel/cpu/intel_epb.c
+++ linux-pm/arch/x86/kernel/cpu/intel_epb.c
@@ -97,7 +97,6 @@ static void intel_epb_restore(void)
 	wrmsrl(MSR_IA32_ENERGY_PERF_BIAS, (epb & ~EPB_MASK) | val);
 }
 
-#ifdef CONFIG_PM
 static struct syscore_ops intel_epb_syscore_ops = {
 	.suspend = intel_epb_save,
 	.resume = intel_epb_restore,
@@ -194,25 +193,6 @@ static int intel_epb_offline(unsigned in
 	return 0;
 }
 
-static inline void register_intel_ebp_syscore_ops(void)
-{
-	register_syscore_ops(&intel_epb_syscore_ops);
-}
-#else /* !CONFIG_PM */
-static int intel_epb_online(unsigned int cpu)
-{
-	intel_epb_restore();
-	return 0;
-}
-
-static int intel_epb_offline(unsigned int cpu)
-{
-	return intel_epb_save();
-}
-
-static inline void register_intel_ebp_syscore_ops(void) {}
-#endif
-
 static __init int intel_epb_init(void)
 {
 	int ret;
@@ -226,7 +206,7 @@ static __init int intel_epb_init(void)
 	if (ret < 0)
 		goto err_out_online;
 
-	register_intel_ebp_syscore_ops();
+	register_syscore_ops(&intel_epb_syscore_ops);
 	return 0;
 
 err_out_online:




  parent reply	other threads:[~2019-05-27 10:56 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-21 22:12 [PATCH 0/2] PM / arch: x86: MSR_IA32_ENERGY_PERF_BIAS handling fixes and sysfs i/f Rafael J. Wysocki
2019-03-21 22:18 ` [PATCH 1/2] PM / arch: x86: Rework the MSR_IA32_ENERGY_PERF_BIAS handling Rafael J. Wysocki
2019-03-22  9:03   ` Hannes Reinecke
2019-03-22 14:28   ` Borislav Petkov
2019-03-22 14:31     ` Thomas Gleixner
2019-03-22 14:35       ` Borislav Petkov
2019-03-22 16:12         ` Thomas Gleixner
2019-03-22 16:52           ` Joe Perches
2019-03-25 10:06     ` Rafael J. Wysocki
2019-03-22 16:27   ` Thomas Renninger
2019-03-22 16:43     ` Borislav Petkov
2019-03-25 11:31   ` Borislav Petkov
2019-03-21 22:20 ` [PATCH 2/2] PM / arch: x86: MSR_IA32_ENERGY_PERF_BIAS sysfs interface Rafael J. Wysocki
2019-03-22  9:03   ` Hannes Reinecke
2019-03-22 14:46   ` Borislav Petkov
2019-03-25 10:01     ` Rafael J. Wysocki
2019-03-22 15:00   ` Peter Zijlstra
2019-03-25  9:56     ` Rafael J. Wysocki
2019-03-25 11:32   ` Borislav Petkov
2019-05-09 10:23   ` Ido Schimmel
2019-05-09 17:18     ` Rafael J. Wysocki
2019-05-09 17:43       ` Ido Schimmel
2019-05-09 21:28         ` [PATCH] x86: intel_epb: Take CONFIG_PM into account Rafael J. Wysocki
2019-05-10  6:01           ` Ingo Molnar
2019-05-27 10:56         ` Rafael J. Wysocki [this message]
2019-05-30  7:47           ` [PATCH] x86: intel_epb: Do not build when CONFIG_PM is unset Ingo Molnar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3844875.YPkTDDlcrF@kreacher \
    --to=rjw@rjwysocki.net \
    --cc=bp@suse.de \
    --cc=hare@suse.de \
    --cc=idosch@idosch.org \
    --cc=labbott@fedoraproject.org \
    --cc=len.brown@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.org \
    --cc=srinivas.pandruvada@linux.intel.com \
    --cc=sschricker@suse.de \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    --subject='Re: [PATCH] x86: intel_epb: Do not build when CONFIG_PM is unset' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
on how to clone and mirror all data and code used for this inbox