On Tue, Jun 18, 2024 at 01:58:07PM -0500, Mario Limonciello wrote: > On 6/18/2024 13:52, Aaron Rainbolt wrote: > > On Tue, Jun 18, 2024 at 01:35:57PM -0500, Mario Limonciello wrote: > > > On 6/18/2024 13:30, Aaron Rainbolt wrote: > > > > On Tue, Jun 18, 2024 at 12:09:19PM -0500, Mario Limonciello wrote: > > > > > On 6/17/2024 21:54, Aaron Rainbolt 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. > > > > > > > > > > > > To work around this, provide a new kernel parameter, > > > > > > "processor.ignore_osc_cppc_bit", which may be used to ignore the _OSC > > > > > > CPPC v2 bit and act as if the bit was enabled. This allows CPPC to be > > > > > > properly detected even if not "enabled" by _OSC, allowing users with > > > > > > problematic hardware to obtain decent single-core performance. > > > > > > > > > > > > Tested-by: Michael Mikowski <mmikowski@xxxxxxxxxx> > > > > > > Signed-off-by: Aaron Rainbolt <arainbolt@xxxxxxxxxx> > > > > > > > > > > This sounds like a platform bug and if we do accept a patch like this I > > > > > think we need a lot more documentation about the situation. > > > > > > > > It is a platform bug, yes. See my previous email, > > > > https://lore.kernel.org/linux-acpi/d01b0a1f-bd33-47fe-ab41-43843d8a374f@xxxxxxxxxx/T/#u > > > > (I meant to send this email as a reply to that one, but failed to do so.) > > > > > > > > > Can you please share more information about your hardware: > > > > > 1) Manufacturer? > > > > > > > > Carbon Systems, models Iridium 14 and Iridium 16. > > > > > > > > > 2) CPU? > > > > > > > > Intel Core i5-13500H. > > > > > > > > > 3) Manufacturer firmware version? > > > > > > > > The systems use an AMI BIOS with version N.1.10CAR01 according to > > > > dmidecode. This is the latest BIOS available from the manufacturer. > > > > > > > > > 4) If it's AMD what's the AGESA version? > > > > > > > > Both affected systems are Intel-based and use heterogenous cores, not AMD. > > > > > > > > > And most importantly do you have the latest system firmware version from > > > > > your manufacturer? If not; please upgrade that first. > > > > > > > > We are using the latest firmware. (We're trying to work with the ODM to > > > > potentially get a firmware update, but since this affects more than just > > > > us and a firmware update may not be possible for everyone, this would > > > > likely be worth providing a kernel-level workaround for.) > > > > > > > > I can easily provide more detailed information - would the full output of > > > > 'dmidecode' and 'acpidump' be useful? > > > > > > Does your BIOS offer any options for these? > > > > > > Intel(R) SpeedStep(TM) > > > Intel Speed Shift Technology(TM) > > > > > > I believe you need those enabled for this to work properly. > > > > Neither option is available in the BIOS settings UI, however our ODM > > confirmed that both Intel Speed Shift Technology and Intel Turbo Boost Max > > Technology 3.0 are enabled by default. They did not mention SpeedStep, > > but I assume SpeedStep is working since frequency scaling in general > > works and the kernel patch fixes the issue. > > Got it. If those are enabled I think it would be good to get comments from > Rafael and Srinivas about your specific situation then. > > But regarding the patch, if they are agreeable to this "kind" of knob for > debugging I personally think it's better to have cpc_supported_by_cpu() look > at the kernel command line than plumb arguments from the module down through > every function. Just to be clear since I'm not all too familiar with how kernel params work, should core_param be used here? Or is there a variable that allows accessing the entire command line to look through it? I don't think I can use module_param in 'arch/x86/kernel/acpi/cppc.c', core_param has a comment over it describing it as "historical" so I don't think I should use it, and early_param looks like something one is only supposed to use in code that runs very early at kernel startup. I can probably figure it out on my own, but a quick pointer would be helpful.
