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

[K Prateek Nayak <kprateek.nayak@amd.com>]

Hello Pintu,

On 7/10/2026 9:31 PM, Pintu Kumar Agarwal wrote:
>>> 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.
>>
>>> 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.
>>
>>> 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?

>>    -> 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?

>> - userspace scheduling delays under high pressure

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

>> - 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.

>> - 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?

>> - useful for minimal environment like initramfs or busybox

Who is doing PSI analysis in these environments?

>>
>> 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.

>> 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.

>> 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.

>>
>> 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.

>>
>>>> +
>>>> +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