Re: [PATCH v2] cpuidle: Deny idle entry when CPU already have IPI interrupt pending

[Maulik Shah (mkshah)]

On 8/21/2026 6:33 PM, Rafael J. Wysocki (Intel) wrote:
> On Fri, Aug 21, 2026 at 11:28 AM Daniel Lezcano
> <daniel.lezcano@xxxxxxxxxxxxxxxx> wrote:
>>
>>
>> Le 21/08/2026 à 07:03, Maulik Shah (mkshah) a écrit :
>>
>> [ ... ]
>>>> What do we do about the cpuidle stats in that case?
>>>> I'm thinking primiarly about last_residency_ns and rejected here.
>>>
>>> As the idle entry will not happen (call_cpuidle() is not invoked)
>>> the stats would also not required to be updated.
>> I agree, with the IPI pending it is like the idle task should have not
>> be scheduled, so the idle call is aborted.
> 
> Which is why I think that this should be handled directly in the idle
> loop and not in cpuidle_enter_state().

The IPI is raised to the idle CPU which is still running cpuidle_select()
but an idle entry with call_cpuidle() is not yet made.

with some additional traces added in menu governor, this is captured on LeMans SoC (8 CPUs) running GLMark2,

     in:imuxsock-1348    [007] d..2.   791.122080: sched_switch: prev_comm=in:imuxsock prev_pid=1348 prev_prio=120 prev_state=S ==> next_comm=swapper/7 next_pid=0 next_prio=120

At this point CPU7 is idle, checking the 8 past samples logged in get_typical_interval(),
at menu governor's menu_select().

          <idle>-0       [007] d..1.   791.122084: cpu_idle_history: samples 0=944 1=26010 2=6821 3=5033 4=664 5=1958 6=15226 7=4977
 systemd-journal-373     [006] d..3.   791.122085: sched_waking: comm=in:imuxsock pid=1348 prio=120 target_cpu=007
          <idle>-0       [007] d..1.   791.122086: cpu_idle_predict_params: max_thresh=4294967295 min_thresh=-1 max=26010 min=664 divisor=8 avg=7704 avg_sq=59351616 variance=66916462
          <idle>-0       [007] d..1.   791.122087: cpu_idle_history: samples 0=944 1=26010 2=6821 3=5033 4=664 5=1958 6=15226 7=4977

CPU6 sends IPI to CPU7 at below point, CPU7 is still in the get_typical_interval() loop.

 systemd-journal-373     [006] d..3.   791.122087: ipi_send_cpu: cpu=7 callsite=ttwu_queue_wakelist+0x118/0x1c0 callback=generic_smp_call_function_single_interrupt+0x0/0x30
          <idle>-0       [007] d..1.   791.122087: cpu_idle_predict_params: max_thresh=26010 min_thresh=-1 max=15226 min=664 divisor=7 avg=5089 avg_sq=25897921 variance=21762726
 systemd-journal-373     [006] d..3.   791.122087: ipi_raise: target_mask=00000000,00000080 (Function call interrupts)
          <idle>-0       [007] d..1.   791.122088: cpu_idle_history: samples 0=944 1=26010 2=6821 3=5033 4=664 5=1958 6=15226 7=4977
          <idle>-0       [007] d..1.   791.122088: cpu_idle_predict_params: max_thresh=15226 min_thresh=-1 max=6821 min=664 divisor=6 avg=3399 avg_sq=11553201 variance=5412374
          <idle>-0       [007] d..1.   791.122091: cpu_idle_sleep_lengths: predicted_ns=4294967295000 next_timer_ns=42336718 timer_us=11215 latency_req=2000000000000

CPU7 would have gone to state=2 (which involves PSCI CPU_SUSPEND SMC call to firmware)

          <idle>-0       [007] d..1.   791.122101: cpu_idle_ipi_pending: IPI pending = 1

With current change, the CPU7 will roll-back to running state.

Thanks,
Maulik

> 
> In that case, cpuidle should not be involved at all (if it is
> sufficiently important for special-casing which I'm still not
> convinced about).