From: John Ogness <john.ogness@linutronix.de>
To: Petr Mladek <pmladek@suse.com>, Tomasz Figa <tfiga@chromium.org>
Cc: Sergey Senozhatsky <senozhatsky@chromium.org>,
Ingo Molnar <mingo@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Juri Lelli <juri.lelli@redhat.com>,
Vincent Guittot <vincent.guittot@linaro.org>,
Dietmar Eggemann <dietmar.eggemann@arm.com>,
Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>,
Steven Rostedt <rostedt@goodmis.org>,
Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] hung_task: configurable hung-task stacktrace loglevel
Date: Mon, 28 Apr 2025 10:11:46 +0206 [thread overview]
Message-ID: <84selszp5x.fsf@jogness.linutronix.de> (raw)
In-Reply-To: <aAuq-3yjYM97rvj1@pathway.suse.cz>
On 2025-04-25, Petr Mladek <pmladek@suse.com> wrote:
> I am afraid that manipulating log levels is a lost fight because
> different people might have different opinion about how various
> messages are important.
Wasn't that the whole point of Sergey's patch? To make it configurable?
I must admit that I am not happy with the patch. Mostly because it is
too specific. And I am not sure if we really want to try to make it all
dynamic with a report API either. At least we need to think about it
more carefully.
One thing that crossed my mind was that we have enter/exit markers for
emergency mode, which should be used whenever something "bad" happens. I
am wondering if a fixed loglevel could be configured for all messages
stored by a CPU in emergency mode. This might also encourage developers
to track down and mark more emergency sections. For the nbcon series, I
really only picked a few obvious ones, but I am sure there are more.
In other words, I would prefer to recycle the emergenceny enter/exit
markers rather than introduce new ones. (Unless we are also talking
about reports that are totally normal and acceptable during runtime.)
John
next prev parent reply other threads:[~2025-04-28 8:05 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-24 7:02 [PATCH] hung_task: configurable hung-task stacktrace loglevel Sergey Senozhatsky
2025-04-24 10:58 ` Petr Mladek
2025-04-25 4:49 ` Sergey Senozhatsky
2025-04-25 14:55 ` Petr Mladek
2025-04-30 1:34 ` Sergey Senozhatsky
2025-04-30 1:57 ` Sergey Senozhatsky
2025-04-25 6:58 ` Tomasz Figa
2025-04-25 15:32 ` Petr Mladek
2025-04-28 8:05 ` John Ogness [this message]
2025-04-30 5:05 ` Sergey Senozhatsky
2025-04-30 8:42 ` Tomasz Figa
2025-05-02 15:05 ` Petr Mladek
2025-05-02 15:30 ` John Ogness
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=84selszp5x.fsf@jogness.linutronix.de \
--to=john.ogness@linutronix.de \
--cc=akpm@linux-foundation.org \
--cc=bsegall@google.com \
--cc=dietmar.eggemann@arm.com \
--cc=juri.lelli@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=pmladek@suse.com \
--cc=rostedt@goodmis.org \
--cc=senozhatsky@chromium.org \
--cc=tfiga@chromium.org \
--cc=vincent.guittot@linaro.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox