Re: [PATCH v2 0/5] s390/idle: CPU idle driver

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

On 6/9/26 14:24, Mete Durlu wrote:
> v1 -> v2:
> 
> * Add idle driver enteries to MAINTAINERS file (Christian Loehle)
> * Remove extra line break left in drivers/cpuidle/Kconfig.s390
>   (Christian Loehle)
> 
> This patch series introduces a CPU idle driver for s390
> architecture that leverages the existing cpu idle infrastructure and
> TEO (Timer Events Oriented) governor to optimize idle state selection
> based on timer events and interrupt patterns.

So if (according to v1) there's no data (yet) that teo is much preferred,
I would remove all mentions of it in code and patch descriptions?
A cpuidle driver requiring a specific governor sort-of violates the
abstraction.
In case teo does work much better for you, which I wouldn't doubt for
a second from what your system looks like, it would be nice to present
some data on it. Additionally I think setting it in the defconfig alone
is probably enough?

> 
> - Implementation Overview
> -----------------------------------------------------------------------
> 
> The driver implements two idle states;
> 
> **Polling Idle (shallow state)**
> - Busy-loop implementation that prevents SIE-exit during short idle periods
> - Zero exit latency, optimized for latency-sensitive workloads
> - Maintains CPU with the guest, improving response times
> 
> **Enabled Wait (deep state)**
> - Traditional EW state that signals hypervisor availability
> - Higher exit latency but more efficient for longer idle periods
> 
> The TEO governor dynamically selects between these states by monitoring
> next timer interrupts and system interrupt frequency, choosing the most
> appropriate idle state for each situation.
> 
> - Performance Benefits
> -----------------------------------------------------------------------
> 
> Benchmark results across LPAR, KVM, and z/VM guests demonstrate significant
> improvements for latency-sensitive and scheduler-intensive workloads:
> 
> ```
> Benchmark    | LPAR  | z/VM  | KVM   |
> -----------------------------------------
> cyclictest   | +45%  | +50%  | +30%  |
> hackbench    | +5%   | +12%  | -     |
> pgbench      | +2%   | +15%  | +2%   |
> uperf        | +50%* | +-5%  | +-5%  |
> ```
> 
> *Single-threaded uperf scenarios show 50-70% improvements on LPAR.
> Multi-threaded results show slight improvements overall.
> 
> Additionally, fio and ioping tests show latency distribution shifts toward
> lower values with reduced minimum and average latencies.
> 
> - Configuration
> -----------------------------------------------------------------------
> 
> Idle state parameters are tuned per hypervisor type after benchmarks:
> 
> **LPAR:**
> - Polling: 5us target residency, 0us exit latency
> - EW: 5us target residency, 5us exit latency
> 
> **KVM/z/VM:**
> - Polling: 1us target residency, 0us exit latency
> - EW: 1us target residency, 1us exit latency
> 
I think this would also be useful in cpuidle-s390.c in particular the
different residency+latency values for LPAR and KVM/z/VM and what they aim
to achieve for you.

Additionally polling is initialised to 0/0 by poll_state.c, so I don't know
where you're taking these values from?