On Wed, Jun 19, 2024 at 07:30:55PM +0200, Rafael J. Wysocki wrote: > On Wednesday, June 19, 2024 7:09:35 PM CEST Rafael J. Wysocki wrote: > > On Wed, Jun 19, 2024 at 6:33 AM Aaron Rainbolt <arainbolt@xxxxxxxxxx> wrote: > > > > > > acpi: Allow ignoring _OSC CPPC v2 bit via kernel parameter > > > > > > The _OSC is supposed to contain a bit indicating whether the hardware > > > supports CPPC v2 or not. This bit is not always set, causing CPPC v2 to > > > be considered absent. This results in severe single-core performance > > > issues with the EEVDF scheduler on heterogenous-core Intel processors. > > > > While some things can be affected by this, I don't immediately see a > > connection between CPPC v2, Intel hybrid processors and EEVDF. > > > > In particular, why would EEVDF alone be affected? > > > > Care to explain this? > > And the reason why I am asking is because I think that you really need > something like this (untested beyond compilation): > > --- > drivers/cpufreq/intel_pstate.c | 16 ++++++++-------- > 1 file changed, 8 insertions(+), 8 deletions(-) > > Index: linux-pm/drivers/cpufreq/intel_pstate.c > =================================================================== > --- linux-pm.orig/drivers/cpufreq/intel_pstate.c > +++ linux-pm/drivers/cpufreq/intel_pstate.c > @@ -355,16 +355,16 @@ static void intel_pstate_set_itmt_prio(i > int ret; > > ret = cppc_get_perf_caps(cpu, &cppc_perf); > - if (ret) > - return; > - > /* > - * On some systems with overclocking enabled, CPPC.highest_perf is hardcoded to 0xff. > - * In this case we can't use CPPC.highest_perf to enable ITMT. > - * In this case we can look at MSR_HWP_CAPABILITIES bits [8:0] to decide. > + * If CPPC is not available, fall back to MSR_HWP_CAPABILITIES bits [8:0]. > + * > + * Also, on some systems with overclocking enabled, CPPC.highest_perf is > + * hardcoded to 0xff, so CPPC.highest_perf cannot be used to enable ITMT. > + * Fall back to MSR_HWP_CAPABILITIES then too. > */ > - if (cppc_perf.highest_perf == CPPC_MAX_PERF) > - cppc_perf.highest_perf = HWP_HIGHEST_PERF(READ_ONCE(all_cpu_data[cpu]->hwp_cap_cached)); > + if (ret || cppc_perf.highest_perf == CPPC_MAX_PERF) > + cppc_perf.highest_perf = > + HWP_HIGHEST_PERF(READ_ONCE(all_cpu_data[cpu]->hwp_cap_cached)); > > /* > * The priorities can be set regardless of whether or not > > > That could work, maybe? It modifies the code path that is being hit, but our systems are not overclocked, and when the patch suggested earlier is in place things "just work" when the right parameter is set, so I don't *think* cppc_perf.highest_perf will be equal to CPPC_MAX_PERF. (I know from https://github.com/StarLabsLtd/firmware/issues/143 that 'ret' will be 0, since cppc_get_perf_caps will error out with "ACPI CPPC: No CPC descriptor for CPU:X", so that code path cannot be triggered in our case unless cppc_perf.highest_pert == CPPC_MAX_PERF.)
