Re: [PATCH 0/2] sched/psi: fix trigger window arithmetic

From: Suren Baghdasaryan

Date: Mon Jul 27 2026 - 02:11:12 EST


On Thu, Jul 23, 2026 at 9:12 PM Tao Cui <cui.tao@xxxxxxxxx> wrote:
>
> From: Tao Cui <cuitao@xxxxxxxxxx>
>
> Two narrow numeric bugs in the PSI trigger-window arithmetic, both from
> the original psi monitor (0e94682b73bf) and both only visible for trigger
> windows larger than ~4.29s (UINT32_MAX ns).
>
> 1/2 window_update() estimates the stall growth inside a partially-elapsed
> window as `prev_growth * remaining / size`. `remaining` is a u32 but
> win->size is a u64 and may be up to 10s (1e10 ns), so for large windows
> it truncates and the interpolation collapses; `prev_growth * remaining`
> can also overflow u64. Use a u64 `remaining` and mul_u64_u64_div_u64().
>
> 2/2 psi_trigger_create() scales window/threshold us->ns with
> `* NSEC_PER_USEC`. NSEC_PER_USEC is `long`, so on 32-bit the multiply
> wraps for multi-second windows (a 10s window is stored as ~1.41s).
> Cast to u64 first.
>
> Neither path is the scheduler hot path (update_triggers() runs at
> trigger-evaluation rate), and small-window triggers are numerically
> unchanged.
>
> Demo of 1/2 -- 10s window, previous window was 100% stall, polled each
> 1s, trigger "some 5s 10s". Estimated growth (seconds) inside the window:
>
> elapsed current(u32) fixed(u64)
> 1 1 10
> 2 2 10
> 3 3 10
> 4 5 10
>
> With the current code the trigger waits for the actual stall to reach the
> 5s threshold (~4s in) instead of firing once the run-rate predicts it
> (~1s in): a ~3s delay on the first window of a stall.

This looks like a duplicate of the series posted by your collegue at
https://lore.kernel.org/all/20260717102824.985950-1-guopeng.zhang@xxxxxxxxx/

>
> Tao Cui (2):
> sched/psi: fix trigger window growth interpolation for large windows
> sched/psi: convert trigger window/threshold to ns in u64
>
> kernel/sched/psi.c | 9 +++++----
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> --
> 2.43.0
>