Re: [PATCH] cpuidle: Add the shallow governors

[Christian Loehle <christian.loehle@arm.com>]

On 10/9/26 17:50, Roman Kagan wrote:
> On Fri, Oct 09, 2026 at 01:45:40PM +0100, Christian Loehle wrote:
>> On 10/9/26 13:12, Roman Kagan wrote:
>>> On Thu, Oct 08, 2026 at 07:29:43PM +0100, Christian Loehle wrote:
>>>> On 10/8/26 19:17, Christian Loehle wrote:
>>>>> On 10/8/26 19:06, Roman Kagan wrote:
>>>>>> The idle states offered by a platform trade wakeup latency for energy
>>>>>> savings, and there are situations where the trade is not worth making:
>>>>>> while a latency-sensitive workload is running, or during a live update
>>>>>> via kexec, where everything from the outgoing kernel stopping the
>>>>>> workload to the incoming kernel resuming it is downtime, and deep idle
>>>>>> states may lengthen it.
>>>>>>
>>>>>> The mechanisms currently available for that are all one-way.
>>>>>> cpuidle.off=1, idle=poll and idle=halt can only be requested in the
>>>>>> kernel command line and cannot be undone, and the PM QoS interfaces
>>>>>> (/dev/cpu_dma_latency and the per-CPU pm_qos_resume_latency_us
>>>>>> attribute) can only be used once user space is up, so they cannot cover
>>>>>> the boot of the incoming kernel.
>>>>>
>>>>> You can also disable all but the shallowest idle state in sysfs:
>>>>> echo 1 > /sys/devices/system/cpu/cpuX/cpuidle/stateX/disable
>>>>>
>>>>
>>>> And I'd probably prefer having that exposed via the cmdline rather than
>>>> two separate governors...
>>>
>>> Doing this cmdline configuration per-cpu per-state is non-realistic.  I
>>> guess you mean a single option that would express a policy, like "for
>>> all cpus in the system, disable all but the shallowest state" or "...
>>> all but the shallowest non-polling".  But policy is exactly what
>>> governors are for.
>>
>> Yes, I had something like
>> cpuidle.max_exit_latency_us=<N>
>> in mind that then sets the disable attribute for the applicable states.
>>
>>>
>>> Why exactly does having two more separate simple, narrow-purpose
>>> governors sound wrong to you?
>>
>> Because it's a lot of duplicate code we have to maintain (and the
>> documentation).
> 
> Fair.  But then PM QoS model appears to fit better.  I'll see to
> reconcile it with the need to be able to set at boot and clear later.
> 

IMO it only seems that way, the need for yet another exposed qos attribute
is why I think I'd prefer the "initialize states as disabled" approach,
but let me consider your v2.