From: "Li,Rongqing" <lirongqing@baidu.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: "corbet@lwn.net" <corbet@lwn.net>,
"lance.yang@linux.dev" <lance.yang@linux.dev>,
"mhiramat@kernel.org" <mhiramat@kernel.org>,
"paulmck@kernel.org" <paulmck@kernel.org>,
"pawan.kumar.gupta@linux.intel.com"
<pawan.kumar.gupta@linux.intel.com>,
"mingo@kernel.org" <mingo@kernel.org>,
"dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
"rostedt@goodmis.org" <rostedt@goodmis.org>,
"kees@kernel.org" <kees@kernel.org>,
"arnd@arndb.de" <arnd@arndb.de>,
"feng.tang@linux.alibaba.com" <feng.tang@linux.alibaba.com>,
"pauld@redhat.com" <pauld@redhat.com>,
"joel.granados@kernel.org" <joel.granados@kernel.org>,
"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: RE: [????] Re: [PATCH][RFC] hung_task: Support to panic when the maximum number of hung task warnings is reached
Date: Tue, 23 Sep 2025 04:00:03 +0000 [thread overview]
Message-ID: <f11f4dd1983f4073a8008112e55f92f8@baidu.com> (raw)
In-Reply-To: <20250922204554.55dd890090b0f56ad10a61f5@linux-foundation.org>
> -----Original Message-----
> From: Andrew Morton <akpm@linux-foundation.org>
> Sent: 2025年9月23日 11:46
> To: Li,Rongqing <lirongqing@baidu.com>
> Cc: corbet@lwn.net; lance.yang@linux.dev; mhiramat@kernel.org;
> paulmck@kernel.org; pawan.kumar.gupta@linux.intel.com; mingo@kernel.org;
> dave.hansen@linux.intel.com; rostedt@goodmis.org; kees@kernel.org;
> arnd@arndb.de; feng.tang@linux.alibaba.com; pauld@redhat.com;
> joel.granados@kernel.org; linux-doc@vger.kernel.org;
> linux-kernel@vger.kernel.org
> Subject: [????] Re: [PATCH][RFC] hung_task: Support to panic when the
> maximum number of hung task warnings is reached
>
> On Tue, 23 Sep 2025 11:37:40 +0800 lirongqing <lirongqing@baidu.com> wrote:
>
> > Currently the hung task detector can either panic immediately or
> > continue operation when hung tasks are detected. However, there are
> > scenarios where we want a more balanced approach:
> >
> > - We don't want the system to panic immediately when a few hung tasks
> > are detected, as the system may be able to recover
> > - And we also don't want the system to stall indefinitely with multiple
> > hung tasks
> >
> > This commit introduces a new mode (value 2) for the hung task panic behavior.
> > When set to 2, the system will panic only after the maximum number of
> > hung task warnings (hung_task_warnings) has been reached.
> >
> > This provides a middle ground between immediate panic and potentially
> > infinite stall, allowing for automated vmcore generation after a
> > reasonable
>
> I assume the same argument applies to the NMI watchdog, to the softlockup
> detector and to the RCU stall detector?
True, especial RCU stall detector
>
> A general framework to handle all of these might be better. But why do it in
> kernel at all? What about a userspace detector which parses kernel logs (or
> new procfs counters) and makes such decisions?
By leveraging existing kernel mechanisms, implementation in kernel is very simple and reliable, I think
Thanks
-Li
next prev parent reply other threads:[~2025-09-23 4:00 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-23 3:37 [PATCH][RFC] hung_task: Support to panic when the maximum number of hung task warnings is reached lirongqing
2025-09-23 3:45 ` Andrew Morton
2025-09-23 3:59 ` Lance Yang
2025-09-23 5:22 ` [外部邮件] " Li,Rongqing
2025-09-23 5:55 ` Lance Yang
2025-09-23 6:19 ` Li,Rongqing
2025-09-23 4:00 ` Li,Rongqing [this message]
2025-09-23 6:03 ` [????] " Paul E. McKenney
2025-09-23 6:16 ` [外部邮件] " Li,Rongqing
2025-09-23 7:01 ` Li,Rongqing
2025-09-23 4:35 ` Randy Dunlap
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f11f4dd1983f4073a8008112e55f92f8@baidu.com \
--to=lirongqing@baidu.com \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=corbet@lwn.net \
--cc=dave.hansen@linux.intel.com \
--cc=feng.tang@linux.alibaba.com \
--cc=joel.granados@kernel.org \
--cc=kees@kernel.org \
--cc=lance.yang@linux.dev \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mhiramat@kernel.org \
--cc=mingo@kernel.org \
--cc=pauld@redhat.com \
--cc=paulmck@kernel.org \
--cc=pawan.kumar.gupta@linux.intel.com \
--cc=rostedt@goodmis.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.