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

Hello Pintu,

On 7/10/2026 9:31 PM, Pintu Kumar Agarwal wrote:

quoted

quoted

There is nothing here that warrants putting this in kernel/sched.

The feature depends on sched/psi so I decided to keep it close.
But I am open for any location.

quoted

Also this gets included by default when config is enabled and starts
dumping a bunch of stats to dmesg without anyone asking. No?

This is included as a dependent feature of PSI.
If someone enables this CONFIG as part of PSI this indicates that they
are interested in getting auto-monitor stats.
Also, the dump will happen only if threshold is breached with high
default values.
However, for RFC stage I wanted to keep things simple.
Later, we can add an enable/disable flag in cmdline just like PSI.

quoted

Afaict, almost all of the detail used here is also available from
procfs and people can easily put together a userspace tool if they
need it. Why do we need an in-kernel module?

This is the most fundamental aspect of this auto-monitor feature.
This point is already described in the cover letter.
Let me put it again:
- Get kernel stats early during boot_time before userspace comes up.

People care about PSI signals at boot, and even before the userspace
is up? Why?

quoted

   -> Set slightly lower threshold and boot stats (helps in analysing boot time)
- No user intervention or continuous polling or daemons needed
  (Just enable config and start auto monitoring)

So overehead for everyone?

quoted

- userspace scheduling delays under high pressure

Even workqueues need scheduling. They don't just automagically run
at the end of the set timer.

quoted

- risk of missing short-lived spikes
- capturing details as soon as pressure hits and at same timestamp

But your data is sampled. So these will still be missed.

quoted

- useful for analysing real-time latency workload.

How often is PSI enabled there. I know for a fact there are certain
locking overheads associated with PSI (like ttwu trying to grab the
rq_lock to migrate PSI signals) and wouldn't most RT be better off
running without those overheads?

quoted

- useful for minimal environment like initramfs or busybox

Who is doing PSI analysis in these environments?

quoted

The motivation is not to replace existing PSI interfaces or the ability
to build userspace monitoring tools.
The goal is attribution at the moment pressure thresholds are crossed.
A userspace implementation observes the system after being scheduled,

Workqueue threads still need scheduling. Just because it is a
kernel thread doesn't mean it gets any privilege.

quoted

whereas the in-kernel implementation captures contributors at the point
where pressure is detected.

Again, your implementation is based on sampling so signals can still
get missed.

quoted

During LPC-2024 I have done significant changes to core psi module
to implement the similar logic.
But the feedback was not to disturb the core psi interface, instead
develop a separate interface and make it configurable.
So, I came up with this auto-monitor idea.

I'll defer to Johannes on this since he knows these bits best.

quoted

For more details please have a look at my OSS paper with data.
https://hosted-files.sched.co/ossindia2026/19/OSS-IND-26-PSI-Auto-Monitor.pdf
And also the reference data here:
https://github.com/pintuk/KERNEL/tree/master/PSI_WORK

I am also looking out for someone who can test this on a larger
workload and capture data.
This will help us to gather insights, how the feature behaves.

I still think periodically walking the entire task tree on a large
server is a very bad idea,especially when people have tens of
thousands of task running.

quoted

quoted

quoted

+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Pintu Kumar Agarwal");
+MODULE_DESCRIPTION("In-kernel PSI automatic monitor with sysfs, weighted scoring and tracepoints");
--

Any other feedback before I post v2 ?

It is the European holiday season so the response might be slow.

I suggest iterating on this only after checking with Johannes.

Another thing that I wanted feedback is, whether to keep under
kernel/sched/ or move under tools/sched/ ?

I think the only dependency here is the "psi_system" which is why you've
kept this in kernel/sched but if you can have an wrapper with an
EXPORT_SYMBOL_GPL(), you should be able to place it in tools/sched.

Again, I would check with Johannes on whether it is acceptable to expose
the PSI internals to modules.

I still think most of this is already visible via sysfs and that might
be a better way to get this information. OOMD is able to use PSI signals
and act on it without needing to be in kernel. What warrants an
in-kernel monitor?

-- 
Thanks and Regards,
Prateek