Skip to content

cpuidle: cpuidle-apple: Reduce target residency for CPU Power Down state#532

Closed
gg582 wants to merge 1 commit into
AsahiLinux:fairydustfrom
maintaining-m1-linux:fix-cpuidle-apple-residency
Closed

cpuidle: cpuidle-apple: Reduce target residency for CPU Power Down state#532
gg582 wants to merge 1 commit into
AsahiLinux:fairydustfrom
maintaining-m1-linux:fix-cpuidle-apple-residency

Conversation

@gg582

@gg582 gg582 commented Jul 1, 2026

Copy link
Copy Markdown

just a minor patch...still okay to be rejected..

Signed-off-by: Lee Yunjin <gzblues61@gmail.com>
@gg582 gg582 force-pushed the fix-cpuidle-apple-residency branch from d7a2408 to ff76e4f Compare July 1, 2026 10:41
@WhatAmISupposedToPutHere

Copy link
Copy Markdown
Member

Can you explain what is the purpose of this change and what exactly it does?

@gg582

gg582 commented Jul 1, 2026

Copy link
Copy Markdown
Author

Summary of the change

This patch reduces the target_residency of the "CPU PD" (Power Down) state from 10,000µs (10ms) to 1,500µs (1.5ms) to allow the CPU/cluster to enter the deeper idle state more aggressively during short idle windows.

Technical Justification

  1. Overestimated Residency: The current value of 10,000µs is excessively high for a modern core architecture like Apple Silicon. Given that the exit_latency is only 10µs, the energy break-even point (the minimum time required to offset the power cost of entering and exiting the power-down state) is much lower than 10ms.

  2. Energy Efficiency in Shallow Idle Patches:
    With a 10ms target residency, the kernel's cpuidle governor (menu or teo) frequently falls back to shallower idle states (or fails to power down the cluster) during typical bursty workloads, even when the CPU could have safely powered down and saved power.

  3. Alignment with Practical Latency:
    Lowering the threshold to 1,500µs ensures a better balance. It allows the cpuidle governor to select the "CPU PD" state more dynamically during short intervals, significantly improving battery life and thermal efficiency without introducing regression in latency overhead.

@gg582

gg582 commented Jul 1, 2026

Copy link
Copy Markdown
Author

I think this PR is at a borderline...it can be considered as an enhancement but when seeing this from different perspective this is a ricing

@gg582 gg582 closed this Jul 3, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants