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
