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

[Daniel Lezcano]

On 3/16/26 10:50, Christian Loehle wrote:

[ ... ]

> > > So we already do a per-CPU IPI need_resched() check in the idle
> > > path.
> >
> > The need_resched() is not the same check. Here the interrupts are
> > off, the test check if there is a pending IPI before entering the
> > sleep routine which will in any case abort because of it. This
> > check saves the costs related to preparing entering the idle
> > state, the call to the firmware and the rollback. Those add an
> > overhead in terms of latency and energy for nothing. As stated in
> > the description, this ultimate check before going idle was
> > introduced also for the cluster idle state and showed a
> > significant improvement [1].
> >
> > [1] https://lore.kernel.org/all/20251105095415.17269-1-
> > ulf.hansson@xxxxxxxxxx/


> So I didn't mean this as "it's unnecessary", but it did make me
> question how big the "performance" impact of this really is, in
> particular for per-CPU idle states (i.e. at most sleep / powerdown
> for you?)

From a per CPU perspective, it is hard to say. It really depends on the 
workload, the number of CPUs and the correctness of the governor prediction.

I would say the higher the number of CPUs, the higher the probability to 
receive an IPI, the lesser the accuracy of the governor [1] and the more 
visible the improvement of this change is.

Maulik did some benchmarking with glmark2 and showed an improvement.


> But if this is only about cluster states (The original
> patch wasn't really clear on that?) then one issue is that the non-
> pmdomain case (e.g. psci PC-mode) we don't actually know what a
> cluster is and therefore which CPUs to check for pending IPIs,
> right?

Ulf changes is for platforms, usually Snapdragon, where the kernel has a 
knowledge of the topology and uses the PSCI-OSI (IIRC). So the kernel is 
in charge of the last-man-standing for the group of CPUs belonging to 
the same cluster. It has all the needed information for this specific 
configuration.

In the case of the PSCI-PC, the firmware is in charge of the cluster 
idling and AFAICT it does a test for pending IRQ / IPI.

  -- Daniel


[1] IPI prediction is not possible because it fully depends on the 
scheduler, so on the behavior of the tasks.