On Thu, Jul 9, 2020 at 11:01 PM Doug Smythies <[email protected]> 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" <[email protected]> > > > > 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 <[email protected]> > > --- > > 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!
