From: Tao Cui <cuitao@kylinos.cn>

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.

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