Re: [PATCH v1 3/3] cpuidle: governors: menu: Special-case nohz_full CPUs

[Rafael J. Wysocki]

Hi,

On Sun, Feb 8, 2026 at 5:00 PM Ionut Nechita (Wind River)
<ionut.nechita@xxxxxxxxxxxxx> wrote:
>
> Hi Rafael,
>
> I have a question regarding this patch: is it planned for upstream
> integration, or is there a newer/improved version in the works?

Not really.

It is too risky to be made at this point because of some systems'
dependency on the current behavior.

> I'm asking because I've been working on a related optimization in the
> same code path. My patch [1] takes a different approach to the same
> problem area -- instead of skipping the override entirely for nohz_full
> CPUs, it changes:
>
>     predicted_ns = data->next_timer_ns;
>
> to:
>
>     predicted_ns = min(predicted_ns, data->next_timer_ns);

This is risky if the next timer is distant because it may cause the
CPU to get stuck in a shallow idle state effectively till the next
timer.  That in turn may prevent the processor as a whole from
entering a package idle state etc.

> The idea is to prevent selecting excessively deep C-states when the
> prediction is short but the next timer is distant, which on platforms
> like Sapphire Rapids with high exit latencies (150us+) can cause
> significant latency spikes.

Well, this essentially is a tradeoff between latency and power.

> I notice that our patches touch the same block but address slightly
> different aspects:
>
> - Your patch: prevents the override from firing on nohz_full CPUs
>   where tick_stopped is always true, avoiding systematically
>   discarding the prediction.
> - My patch: when the override does fire, uses min() instead of
>   unconditional replacement to preserve information from the
>   prediction.
>
> These two fixes could potentially be complementary. However, my patch
> is still under investigation due to limited hardware availability for
> collecting more data across different platforms.
>
> I'd appreciate your thoughts on whether these approaches could be
> combined, or if your patch already addresses the use cases I'm seeing.

Actually, I don't think that any of them are suitable.

Please see this series:

https://lore.kernel.org/linux-pm/1953482.tdWV9SEqCh@rafael.j.wysocki/

which takes a somewhat different direction.