Re: [PATCH v2 2/2] ACPI: processor: idle: Replace single idle driver with per-CPU model for better hybrid CPU support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




在 2025/8/25 22:56, Rafael J. Wysocki 写道:
On Thu, Aug 14, 2025 at 9:32 AM Yaxiong Tian <tianyaxiong@xxxxxxxxxx> wrote:
Current implementations of hybrid architectures (e.g., ARM64 big.LITTLE
and Intel Alder Lake) feature CPU cores with different exit latencies.
This is not true for Intel platforms, all of the CPUs in there have
the same set of C-states.
Yes,it is.

Using a single driver to describe_LPI states for all core types is
therefore suboptimal. This is further supported by ACPI specification
8.4.4.1 which states: "In a processor hierarchy, each node has its
own _LPI low-power states specific to that node."

To address these limitations, we replace the monolithic idle driver
It cannot be replaced or you potentially open a Pandora's box of
regressions on old systems in the field.
I agree with this point. Regarding the potential risk, does it
make sense to  mitigate it through the following two approaches?

1) Restrict the usage of this multiple driver functionality to
the ARM64 platform only.
2) Use a mutex-protected global variable to indicate whether
the platform utilizes _LPI instead of C-states. This variable
would be determined during initialization via
acpi_has_method(handle, "_LPI"), and the multiple driver
would only be used if the platform employs _LPI.

Alternatively, the other option is to let users implement their
own drivers. Although many ARM64 users still initialize their
systems using the ACPI method rather than the traditional
device tree approach, and they hope to reuse the ACPI idle driver.

with a per-CPU model. This approach enables accurate idle state representation
for each core type
The per-CPU model can be used instead of the "monolithic idle driver"
only if the platform is actually known to be hybrid.
Yes,select CPU_IDLE_MULTIPLE_DRIVERS if ARM64  can  resolve this issue.

Tested-by: Shaobo Huang <huangshaobo2075@xxxxxxxxxxxxxx>
Signed-off-by: Yaxiong Tian <tianyaxiong@xxxxxxxxxx>
Signed-off-by: Shaobo Huang <huangshaobo2075@xxxxxxxxxxxxxx>
Signed-off-by: Yinfeng Wang <wangyinfeng@xxxxxxxxxxxxxx>
Signed-off-by: Xu Wang<wangxu@xxxxxxxxxxxxxx>
What do all of the above S-o-b mean?  Are these people involved in the
development of the code?  In that case Co-developed-by is also needed.

Thanks!
Thank you for your response. If it makes sense, continue to follow up,
I will address both the issues mentioned above and the problem
in the previous patch.





[Index of Archives]     [Linux IBM ACPI]     [Linux Power Management]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]
  Powered by Linux