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

[Pierre Gondois <pierre.gondois@arm.com>]

Hello Shaobo,

On 6/16/25 09:14, 黄少波 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. 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?
>
> Thanks,
>
> 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.

Just to confirm that I can reproduce this.

Sudeep will be back in a few days, in case he has more background or
another view on the topic,
but I agree asymmetric _LPI states should ideally be visible to the kernel.

I am having a look at the code aswell. In case you have an
implementation, I can provide additional testing.

Regards,

Pierre

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.