From: John Ogness <john.ogness@linutronix.de>
To: "Jason A. Donenfeld" <Jason@zx2c4.com>,
Petr Mladek <pmladek@suse.com>, Marco Elver <elver@google.com>,
linux-kernel@vger.kernel.org,
Sergey Senozhatsky <senozhatsky@chromium.org>,
Steven Rostedt <rostedt@goodmis.org>
Subject: Re: [PATCH v2] printk: allow direct console printing to be enabled always
Date: Mon, 20 Jun 2022 01:23:04 +0206 [thread overview]
Message-ID: <87letsw8en.fsf@jogness.linutronix.de> (raw)
In-Reply-To: <20220619204326.556923-1-Jason@zx2c4.com>
On 2022-06-19, "Jason A. Donenfeld" <Jason@zx2c4.com> wrote:
> diff --git a/init/Kconfig b/init/Kconfig
> index c7900e8975f1..47466aa2b0e8 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
Sorry, I missed this in your v1. But I think this config belongs in
lib/Kconfig.debug under the "printk and dmesg options" menu.
> @@ -798,6 +798,18 @@ config PRINTK_INDEX
>
> There is no additional runtime cost to printk with this enabled.
>
> +config PRINTK_DIRECT
> + bool "Attempt to flush printk output immediately"
> + depends on PRINTK
> + help
> + Rather than using kthreads for printk output, always attempt to write
> + to the console immediately. This has performance implications, but
> + will result in a more faithful ordering and interleaving with other
> + processes writing to the console.
> +
> + Say N here unless you really need this. This may also be controlled
> + at boot time with printk.direct=0/1.
> +
> #
> # Architectures with an unreliable sched_clock() should select this:
> #
> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> index ea3dd55709e7..43f8a0074ed6 100644
> --- a/kernel/printk/printk.c
> +++ b/kernel/printk/printk.c
> @@ -178,6 +178,14 @@ static int __init control_devkmsg(char *str)
> }
> __setup("printk.devkmsg=", control_devkmsg);
>
> +static bool printk_direct = IS_ENABLED(CONFIG_PRINTK_DIRECT);
I understand why you would name the variable to match the boot arg. But
I would prefer the _internal_ variable had a name that makes it clear
(to us developers) that it is a permanent setting. Perhaps
printk_direct_only or printk_direct_always?
The reason is because when kthreads are active, direct printing is
turned on and off dynamically (using @printk_prefer_direct). And if this
new variable is named @printk_direct, one could easily mistake its
meaning to be related to the dynamic turning on and off.
> +
> +static int __init control_printk_direct(char *str)
> +{
> + return kstrtobool(str, &printk_direct);
> +}
> +__setup("printk.direct=", control_printk_direct);
> +
> char devkmsg_log_str[DEVKMSG_STR_MAX_SIZE] = "ratelimit";
> #if defined(CONFIG_PRINTK) && defined(CONFIG_SYSCTL)
> int devkmsg_sysctl_set_loglvl(struct ctl_table *table, int write,
> @@ -3602,6 +3610,9 @@ static int __init printk_activate_kthreads(void)
> {
> struct console *con;
>
> + if (printk_direct)
I'm wondering if we should output a message here. My suggestion is:
pr_info("printing threads disabled, using direct printing\n");
> + return 0;
> +
> console_lock();
> printk_kthreads_available = true;
> for_each_console(con)
Otherwise it looks OK to me. But you may want to wait on a response from
Petr, Sergey, or Steven before sending a v3. You are adding a kernel
config and a boot argument. Both of these are sensitive topics that
require more feedback from others.
John Ogness
next prev parent reply other threads:[~2022-06-19 23:17 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-17 13:23 5.19 printk breaks message ordering Jason A. Donenfeld
2022-06-17 13:37 ` Jason A. Donenfeld
2022-06-17 13:38 ` [PATCH] printk: allow direct console printing to be enabled always Jason A. Donenfeld
2022-06-19 0:30 ` Randy Dunlap
2022-06-19 8:37 ` Jason A. Donenfeld
2022-06-19 11:05 ` John Ogness
2022-06-19 20:39 ` Jason A. Donenfeld
2022-06-19 20:43 ` [PATCH v2] " Jason A. Donenfeld
2022-06-19 23:17 ` John Ogness [this message]
2022-06-19 23:28 ` Jason A. Donenfeld
2022-06-19 23:33 ` [PATCH v3] " Jason A. Donenfeld
2022-06-20 16:58 ` Petr Mladek
2022-06-20 17:03 ` Jason A. Donenfeld
2022-06-21 9:43 ` David Laight
2022-06-21 9:59 ` Jason A. Donenfeld
2022-06-22 12:55 ` Jason A. Donenfeld
2022-06-20 4:04 ` [PATCH v2] " David Laight
2022-06-20 5:17 ` Sergey Senozhatsky
2022-06-20 7:56 ` Jason A. Donenfeld
2022-06-21 1:34 ` Sergey Senozhatsky
2022-06-21 21:47 ` John Ogness
2022-06-17 14:21 ` 5.19 printk breaks message ordering Petr Mladek
2022-06-17 14:41 ` Jason A. Donenfeld
2022-06-17 15:01 ` David Laight
2022-06-19 8:15 ` John Ogness
2022-06-19 14:24 ` David Laight
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=87letsw8en.fsf@jogness.linutronix.de \
--to=john.ogness@linutronix.de \
--cc=Jason@zx2c4.com \
--cc=elver@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=pmladek@suse.com \
--cc=rostedt@goodmis.org \
--cc=senozhatsky@chromium.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.