Messages in this thread | | | Date | Thu, 30 May 2019 09:47:10 +0200 | From | Ingo Molnar <> | Subject | Re: [PATCH] x86: intel_epb: Do not build when CONFIG_PM is unset |
| |
* Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> 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.
Sure:
Acked-by: Ingo Molnar <mingo@kernel.org>
Thanks,
Ingo
| |