Re: [RFC PATCH 0/1] psi: Introduce in-kernel PSI auto monitor feature

[Johannes Weiner <hannes@cmpxchg.org>]

On Thu, Jul 02, 2026 at 10:46:05PM +0530, Pintu Kumar Agarwal wrote:
> Hi all,
> 
> This RFC introduces an in-kernel PSI auto monitor aimed at improving
> root-cause visibility for resource pressure events in Linux systems.
> 
> Motivation:
> 
> PSI already provides an excellent mechanism to detect CPU, memory and
> I/O pressure and includes trigger-based notifications via pollable
> interfaces. However, it deliberately avoids attributing pressure to
> individual tasks.

Why is this necessary?

> In real-world systems, this creates a gap: when a PSI trigger fires,
> users still need to determine *which tasks caused the stall* by combining
> multiple tools (top, meminfo, vmstat, perf, tracing, etc.), often after
> the event has already passed.

I've never found myself needing to identify which specific task was
stalled. Tasks competing over a shared resource are interdependent.

Consider this scenario: Task A, B, C are allocating memory and
creating pressure together; B randomly becomes the sucker to hit
direct reclaim and making room for the other too as well. Why is it
meaningful to know that B stalled? It caused the resource contention
no more than the other two.

Then A and C refault: A is fast, but C happens to hit when the flash
drive is running garbage collection. Why is it meaningful to know C?
Again, C is no more the culprit in that situation than the others.

The meaningful thing you can say is that the domain as a whole is
under pressure. Who exactly becomes the lightning rod is noise.

That said, if you do need it, why not use delayacct? It already tracks
the reclaim, swap, thrashing time and events that also go into psi on
a per-task basis. It's not sampled, either.