Messages in this thread |  | | Date | Sun, 30 Nov 2025 12:11:55 -0500 | | From | Aaron Tomlin <> | | Subject | Re: [PATCH] hung_task: Migrate hung_task_detect_count to sysfs |
| |
On Sun, Nov 30, 2025 at 01:43:51PM +0800, Lance Yang wrote: > Hi Aaron,
Hi Lance,
> Thanks for the patch.
No problem.
> Emm, I don't think we should do this :) > > Removing the sysctl file is going to break userspace tools that > currently read it ...
Thank you for your feedback. I appreciate the concern regarding user-space compatibility and the potential maintenance overhead of dual interfaces.
I agree that removing the sysctl entry entirely right now is too disruptive, as it would immediately break existing user-space tools relying on /proc/sys/kernel/hung_task_detect_count. Your point about avoiding unnecessary churn and maintaining two interfaces is well-taken.
However, I believe that moving the counter to sysfs is still a worthwhile long-term goal for the following reasons:
1. Consistency and standardisation: Moving read-only counters to /sys/kernel/ aligns with current kernel conventions and provides a more consistent location for performance and diagnostic metrics. This follows the pattern of existing counters like /sys/kernel/softlockup_count.
2. Graceful Migration Path: By adding the /sys/kernel/hung_task_detect_count entry first (as a read-only counter) and keeping the legacy /proc/sys/kernel/hung_task_detect_count file in place, we provide the necessary backwards compatibility and offer a grace period for user-space tools to migrate. The old sysctl file can then be flagged for deprecation in a future release.
I am currently working on some additional updates for kernel/hung_task.c. I believe integrating the sysfs entry now, while I am already touching this file, would be an efficient and worthwhile start.
My proposal is to modify the patch to add the sysfs entry while preserving the existing sysctl entry for the immediate future. If you agree that this phased migration is a worthwhile endeavor, I will prepare and submit a v2 patch that implements this dual-interface approach.
Please let me know your thoughts on this approach for phased migration.
Thanks, -- Aaron Tomlin
|  |