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 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.