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

[黄少波 <huangshaobo2075@phytium.com.cn>]

> 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.
> 
> > 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.

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][follow-up] _LPI path also assumes shared cpuidle_driver, breaks on big.LITTLE

Hi all,

Thanks Rafael for the quick feedback on my earlier question regarding asymmetric idle states on big.LITTLE SoCs.

As a follow-up, after reviewing the implementation further, I noticed that `acpi_processor_setup_lpi_states()` is only called from within
`acpi_processor_setup_cpuidle_states()`, which is itself only invoked once — during initialization of the first CPU.

Specifically:

- The kernel uses a shared global cpuidle_driver instance (`acpi_idle_driver`), which is only initialized once in `acpi_processor_power_init()`:

  static int acpi_processor_registered;
  ...
  if (!acpi_processor_registered) {
      acpi_processor_setup_cpuidle_states(pr);
      cpuidle_register_driver(&acpi_idle_driver);
  }

- Subsequent CPUs only register their cpuidle_device without updating the shared driver's states[] array.

- Even in `acpi_processor_power_state_has_changed()`, only `pr->id == 0` triggers `acpi_processor_setup_cpuidle_states()`, meaning the global
  state array is populated based only on CPU 0.

    int acpi_processor_power_state_has_changed(struct acpi_processor *pr) {
        ...
        if (pr->id == 0 && cpuidle_get_driver() == &acpi_idle_driver) {
            ...
            acpi_processor_setup_cpuidle_states(pr);
            ...
        }
    }

The ACPI _LPI specification allows firmware to describe per-CPU or per-cluster idle state characteristics (latency, residency, etc.). However,
the current implementation effectively ignores this flexibility and applies the first CPU’s states globally.

This appears to be a design limitation that prevents accurate modeling of asymmetric CPU topologies like big.LITTLE. As a result, idle states may
not reflect the correct characteristics for all cores, leading to suboptimal behavior.

Could you please confirm whether this behavior is an intentional carry-over from the legacy _CST-based implementation, or simply an area that hasn't
been fully extended to support _LPI's per-CPU flexibility?

We are actively using the ACPI-based _LPI method on asymmetric ARM64 platforms, so this behavior is directly impacting us. I’d be happy to help investigate
a fix if the current design is not intentional.

Additionally, I’ve reviewed the `bl_idle_init()` implementation in the big.LITTLE device-tree-based driver and confirmed it does not support ACPI.
Since our platform relies on _LPI via ACPI, this limitation is particularly relevant in our use case.

Thanks for your time and insights!

Best regards,
Shaobo Huang


信息安全声明：本邮件包含信息归发件人所在组织所有,发件人所在组织对该邮件拥有所有权利。请接收者注意保密,未经发件人书面许可,不得向任何第三方组织和个人透露本邮件所含信息。
Information Security Notice: The information contained in this mail is solely property of the sender's organization.This mail communication is confidential.Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.