linux-kernel - Re: [PATCH V3] acpi: Allow ignoring _OSC CPPC v2 bit via kernel parameter

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Wed, 19 Jun 2024 12:34:22 -0500
From: Aaron Rainbolt <arainbolt@...cus.org>
To: "Rafael J. Wysocki" <rafael@...nel.org>
Cc: Mario Limonciello <mario.limonciello@....com>,
	linux-acpi@...r.kernel.org, linux-kernel@...r.kernel.org,
	lenb@...nel.org, mmikowski@...cus.org, Perry.Yuan@....com
Subject: Re: [PATCH V3] acpi: Allow ignoring _OSC CPPC v2 bit via kernel
 parameter

On Wed, Jun 19, 2024 at 07:09:35PM +0200, Rafael J. Wysocki wrote:
> On Wed, Jun 19, 2024 at 6:33 AM Aaron Rainbolt <arainbolt@...cus.org> 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?

>From what I understand, the EEVDF scheduler requires ITMT (which in turn
requires CPPC v2) in order to determine which cores are performance cores
and which cores are efficiency cores. When CPPC v2 is missing, ITMT is
also missing, and the scheduler no longer can figure out which cores are
which. Thus on a system with many efficiency cores and a few performance
cores, there's a pretty decent chance the scheduler will put an intensive
single-threaded load on an efficiency core rather than on a performance
core, which has obvious performance implications since efficiency cores
are slower than performance cores by design.

A good example of someone else hitting this issue can be seen here:
https://bugzilla.kernel.org/show_bug.cgi?id=218195 This issue was brought
onto the LKML here:
https://lore.kernel.org/lkml/a106fb4733d0a3f0d6d5792705cdb5cee13731f8.camel@linux.intel.com/T/
Srinivas would have more info here, but I do not have his email so I can't
CC him on this.
 
> > To work around this, provide a new kernel parameter, "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.