Re: Subject: [cpuidle] Limitation: cannot model asymmetric C-state latencies on big.LITTLE SoCs

[Sudeep Holla <sudeep.holla@arm.com>]

On Mon, Jun 16, 2025 at 01:29:15PM +0200, Rafael J. Wysocki wrote:
> On Mon, Jun 16, 2025 at 9:14 AM 黄少波 <huangshaobo2075@phytium.com.cn> wrote:
> >
> > From: huangshaobo2075@phytium.com.cn
> > To: linux-pm@vger.kernel.org
> > Cc: rafael@kernel.org, lenb@kernel.org, deepthi@linux.vnet.ibm.com, khilman@kernel.org
> > Subject: [cpuidle] Limitation: cannot model asymmetric C-state latencies on big.LITTLE SoCs
> >
> > Hi,
> >
> > I'm working on an ARM64 platform with a big.LITTLE CPU topology. While parsing the ACPI tables,
> > I noticed that the C-state latency and residency values differ between the big and LITTLE cores,
> > as expected.
> >
> > However, I found that the current cpuidle framework only allows a single global `cpuidle_driver`,
> > and all CPUs share the same `cpuidle_driver->states[]` array.
> 
> Not really, see bl_idle_init() in particular.
> 
> However, on systems with ACPI on which _CST is used for idle state
> description, there's only one cpuidle driver and one table of idle
> states for all CPUs.
> 

Indeed.

> > As a result, only the first core to
> > initialize (usually a LITTLE core) sets up the C-states, and the same values are applied to all cores,
> > including the big ones. This leads to incorrect idle behavior on asymmetric platforms.
> >
> > I believe this behavior was introduced by commit 46bcfad7a819
> > ("cpuidle: Single/Global registration of idle states").
> >
> > I understand this design was introduced in 2011 to simplify cpuidle and reduce memory usage:
> > https://lkml.org/lkml/2011/4/25/83
> >
> > However, on today's heterogeneous SoCs, this global model no longer suffices. For proper modeling,
> > we need support for per-cluster or per-core cpuidle drivers, or at least some mechanism to allow
> > different idle state parameters per CPU.
> >
> > Has there been any discussion or work toward lifting this limitation?
> 
> No, there's not been any discussion on this so far, but why does the
> platform firmware on this system use _CST for idle state description?
> _LPI would be a better option AFAICS.
> 

Absolutely _LPI is better and I believe _LPI is used in this case. However
at the time I added _LPI support, the expectation was to use ACPI on SMP
systems without such variations in the idle states. So even with _LPIs,
only one cpuidle driver and hence only one table of idle states for all CPUs
was added. We can enhance the support for HMP systems with different set of
idle states if required. All we need is to allocate the driver instead of
using acpi_idle_driver IIRC. The initialisation of the states is already done
per cpu.

-- 
Regards,
Sudeep