[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ll74yi3miktap7ljxx2fenzhqanqikk5pibvcpfhqed6k3eugj@yga4f4yjzndo>
Date: Sun, 30 Nov 2025 12:11:55 -0500
From: Aaron Tomlin <atomlin@...mlin.com>
To: Lance Yang <lance.yang@...ux.dev>
Cc: linux-kernel@...r.kernel.org, mhiramat@...nel.org,
akpm@...ux-foundation.org, gregkh@...uxfoundation.org, Petr Mladek <pmladek@...e.com>
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
Powered by blists - more mailing lists