Re: [PATCH v2 1/4] cpuidle: Skip governor when only one idle state is available

[Rafael J. Wysocki]

On Thu, Mar 5, 2026 at 5:53 PM Guenter Roeck <linux@xxxxxxxxxxxx> wrote:
>
> Hi,
>
> On Tue, Feb 17, 2026 at 12:20:02AM +0530, Aboorva Devarajan wrote:
> > On certain platforms (PowerNV systems without a power-mgt DT node),
> > cpuidle may register only a single idle state. In cases where that
> > single state is a polling state (state 0), the ladder governor may
> > incorrectly treat state 1 as the first usable state and pass an
> > out-of-bounds index. This can lead to a NULL enter callback being
> > invoked, ultimately resulting in a system crash.
> >
> > [   13.342636] cpuidle-powernv : Only Snooze is available
> > [   13.351854] Faulting instruction address: 0x00000000
> > [   13.376489] NIP [0000000000000000] 0x0
> > [   13.378351] LR  [c000000001e01974] cpuidle_enter_state+0x2c4/0x668
> >
> > Fix this by adding a bail-out in cpuidle_select() that returns state 0
> > directly when state_count <= 1, bypassing the governor and keeping the
> > tick running.
> >
> > Fixes: dc2251bf98c6 ("cpuidle: Eliminate the CPUIDLE_DRIVER_STATE_START symbol")
> > Signed-off-by: Aboorva Devarajan <aboorvad@xxxxxxxxxxxxx>
> > ---
> >  drivers/cpuidle/cpuidle.c | 10 ++++++++++
> >  1 file changed, 10 insertions(+)
> >
> > diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
> > index c7876e9e024f..65fbb8e807b9 100644
> > --- a/drivers/cpuidle/cpuidle.c
> > +++ b/drivers/cpuidle/cpuidle.c
> > @@ -359,6 +359,16 @@ noinstr int cpuidle_enter_state(struct cpuidle_device *dev,
> >  int cpuidle_select(struct cpuidle_driver *drv, struct cpuidle_device *dev,
> >                  bool *stop_tick)
> >  {
> > +     /*
> > +      * If there is only a single idle state (or none), there is nothing
> > +      * meaningful for the governor to choose. Skip the governor and
> > +      * always use state 0 with the tick running.
> > +      */
> > +     if (drv->state_count <= 1) {
> > +             *stop_tick = false;
> > +             return 0;
> > +     }
> > +
>
> An experimental AI review agent provided the following feedback:
>
>  Does this unconditionally keep the tick running on systems that only have a
>  single non-polling idle state (like basic ARM systems that only support WFI)?
>
>  Before this patch, governors like menu would check CPUIDLE_FLAG_POLLING before
>  deciding to keep the tick running. Could this change effectively disable
>  NO_HZ_IDLE on these systems, causing higher power consumption?
>
> I don't know scheduling well enough to understand if this is a real problem,
> but I thought it is worth mentioning it.
>
> Please let me know if the problem is real or not so I can feed it back into
> the agent.

On bare metal, this isn't a problem at least in practice because the
only available idle state cannot be too deep anyway, so stopping the
tick doesn't improve energy efficiency too much and it adds overhead.

On virt, it may be a problem if the tick that runs in the VM
effectively prevents the host from using deep idle states, but that
would only matter for VMs running on systems that have deep enough
idle state in configurations where the VM has only one idle state.

This is kind of under discussion in a separate thread here:
https://lore.kernel.org/lkml/20260301192915.171574741@xxxxxxxxxx/#r