Shuai Xue <xueshuai@xxxxxxxxxxxxxxxxx> writes: > 在 2025/2/19 05:33, Ankur Arora 写道: >> Needed for cpuidle-haltpoll. >> Acked-by: Will Deacon <will@xxxxxxxxxx> >> Signed-off-by: Ankur Arora <ankur.a.arora@xxxxxxxxxx> >> --- >> arch/arm64/kernel/idle.c | 1 + >> 1 file changed, 1 insertion(+) >> diff --git a/arch/arm64/kernel/idle.c b/arch/arm64/kernel/idle.c >> index 05cfb347ec26..b85ba0df9b02 100644 >> --- a/arch/arm64/kernel/idle.c >> +++ b/arch/arm64/kernel/idle.c >> @@ -43,3 +43,4 @@ void __cpuidle arch_cpu_idle(void) >> */ >> cpu_do_idle(); > > Hi, Ankur, > > With haltpoll_driver registered, arch_cpu_idle() on x86 can select > mwait_idle() in idle threads. > > It use MONITOR sets up an effective address range that is monitored > for write-to-memory activities; MWAIT places the processor in > an optimized state (this may vary between different implementations) > until a write to the monitored address range occurs. MWAIT is more capable than WFE -- it allows selection of deeper idle state. IIRC C2/C3. > Should arch_cpu_idle() on arm64 also use the LDXR/WFE > to avoid wakeup IPI like x86 monitor/mwait? Avoiding the wakeup IPI needs TIF_NR_POLLING and polling in idle support that this series adds. As Haris notes, the negative with only using WFE is that it only allows a single idle state, one that is fairly shallow because the event-stream causes a wakeup every 100us. -- ankur
