From: Petr Mladek <pmladek@suse.com>
To: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
Dmitriy Vyukov <dvyukov@google.com>,
Steven Rostedt <rostedt@goodmis.org>,
Alexander Potapenko <glider@google.com>,
Fengguang Wu <fengguang.wu@intel.com>,
Josh Poimboeuf <jpoimboe@redhat.com>,
LKML <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org, Ingo Molnar <mingo@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Will Deacon <will.deacon@arm.com>
Subject: Re: [PATCH 3/3] lockdep: Use line-buffered printk() for lockdep messages.
Date: Fri, 23 Nov 2018 13:52:19 +0100 [thread overview]
Message-ID: <20181123125219.k5flkypofll7jwtr@pathway.suse.cz> (raw)
In-Reply-To: <2d0d1f60-d8b6-41e0-6845-0eb62f211e40@i-love.sakura.ne.jp>
On Sat 2018-11-10 17:52:17, Tetsuo Handa wrote:
> On 2018/11/10 0:43, Petr Mladek wrote:
> > On Fri 2018-11-09 18:55:26, Tetsuo Handa wrote:
> >> How early_printk requirement affects line buffered printk() API?
> >>
> >> I don't think it is impossible to convert from
> >>
> >> printk("Testing feature XYZ..");
> >> this_may_blow_up_because_of_hw_bugs();
> >> printk(KERN_CONT " ... ok\n");
> >>
> >> to
> >>
> >> printk("Testing feature XYZ:\n");
> >> this_may_blow_up_because_of_hw_bugs();
> >> printk("Testing feature XYZ.. ... ok\n");
> >>
> >> in https://lore.kernel.org/lkml/CA+55aFwmwdY_mMqdEyFPpRhCKRyeqj=+aCqe5nN108v8ELFvPw@mail.gmail.com/ .
> >
> > I just wonder how this pattern is common. I have tried but I failed
> > to find any instance.
> >
> > This problem looks like a big argument against explicit buffers.
> > But I wonder if it is real.
>
> An example of boot up messages where buffering makes difference.
>
> Vanilla:
>
> [ 0.260459] smp: Bringing up secondary CPUs ...
> [ 0.269595] x86: Booting SMP configuration:
> [ 0.270461] .... node #0, CPUs: #1
> [ 0.066578] Disabled fast string operations
> [ 0.066578] mce: CPU supports 0 MCE banks
> [ 0.066578] smpboot: CPU 1 Converting physical 2 to logical package 1
> [ 0.342569] #2
> [ 0.066578] Disabled fast string operations
> [ 0.066578] mce: CPU supports 0 MCE banks
> [ 0.066578] smpboot: CPU 2 Converting physical 4 to logical package 2
> [ 0.413442] #3
> [ 0.066578] Disabled fast string operations
> [ 0.066578] mce: CPU supports 0 MCE banks
> [ 0.066578] smpboot: CPU 3 Converting physical 6 to logical package 3
> [ 0.476562] smp: Brought up 1 node, 4 CPUs
> [ 0.477477] smpboot: Max logical packages: 8
> [ 0.477514] smpboot: Total of 4 processors activated (22691.70 BogoMIPS)
>
> With try_buffered_printk() patch:
>
> [ 0.279768] smp: Bringing up secondary CPUs ...
> [ 0.288825] x86: Booting SMP configuration:
> [ 0.066748] Disabled fast string operations
> [ 0.066748] mce: CPU supports 0 MCE banks
> [ 0.066748] smpboot: CPU 1 Converting physical 2 to logical package 1
> [ 0.066748] Disabled fast string operations
> [ 0.066748] mce: CPU supports 0 MCE banks
> [ 0.066748] smpboot: CPU 2 Converting physical 4 to logical package 2
> [ 0.066748] Disabled fast string operations
> [ 0.066748] mce: CPU supports 0 MCE banks
> [ 0.066748] smpboot: CPU 3 Converting physical 6 to logical package 3
> [ 0.495862] .... node #0, CPUs: #1 #2 #3\x016smp: Brought up 1 node, 4 CPUs
> [ 0.496833] smpboot: Max logical packages: 8
> [ 0.497609] smpboot: Total of 4 processors activated (22665.22 BogoMIPS)
>
>
>
> Hmm, arch/x86/kernel/smpboot.c is not emitting '\n' after #num
>
> if (system_state < SYSTEM_RUNNING) {
> if (node != current_node) {
> if (current_node > (-1))
> pr_cont("\n");
> current_node = node;
>
> printk(KERN_INFO ".... node %*s#%d, CPUs: ",
> node_width - num_digits(node), " ", node);
> }
>
> /* Add padding for the BSP */
> if (cpu == 1)
> pr_cont("%*s", width + 1, " ");
>
> pr_cont("%*s#%d", width - num_digits(cpu), " ", cpu);
>
> } else
> pr_info("Booting Node %d Processor %d APIC 0x%x\n",
> node, cpu, apicid);
>
> and causing
>
> pr_info("Brought up %d node%s, %d CPU%s\n",
> num_nodes, (num_nodes > 1 ? "s" : ""),
> num_cpus, (num_cpus > 1 ? "s" : ""));
>
> line to be concatenated to previous line.
> Maybe disable try_buffered_printk() if system_state !=
> SYSTEM_RUNNING ?
We need to solve continuous lines also during boot. Also similar
problems might be in the code that is called in SYSTEM_RUNNING state.
This is yet another clue that try_buffered_printk() approach is not
that good idea.
Best Regards,
Petr
next prev parent reply other threads:[~2018-11-23 12:52 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-02 13:31 [PATCH v6 1/3] printk: Add line-buffered printk() API Tetsuo Handa
2018-11-02 13:31 ` [PATCH 2/3] mm: Use line-buffered printk() for show_free_areas() Tetsuo Handa
2018-11-07 14:07 ` Petr Mladek
2018-11-02 13:31 ` [PATCH 3/3] lockdep: Use line-buffered printk() for lockdep messages Tetsuo Handa
2018-11-02 13:36 ` Peter Zijlstra
2018-11-03 2:00 ` Tetsuo Handa
2018-11-06 8:38 ` Petr Mladek
2018-11-06 9:05 ` Sergey Senozhatsky
2018-11-06 12:57 ` Petr Mladek
2018-11-06 9:56 ` Tetsuo Handa
2018-11-07 15:19 ` Petr Mladek
2018-11-08 4:45 ` Sergey Senozhatsky
2018-11-08 11:37 ` Tetsuo Handa
2018-11-09 6:12 ` Sergey Senozhatsky
2018-11-09 9:55 ` Tetsuo Handa
2018-11-09 15:43 ` Petr Mladek
2018-11-10 2:42 ` Tetsuo Handa
2018-11-23 12:46 ` Petr Mladek
2018-11-23 13:12 ` Tetsuo Handa
2018-11-23 15:56 ` Steven Rostedt
2018-11-24 0:24 ` Tetsuo Handa
2018-11-26 4:34 ` Sergey Senozhatsky
2018-11-28 13:29 ` David Laight
2018-11-29 10:09 ` Tetsuo Handa
2018-11-30 16:01 ` Petr Mladek
2018-11-10 8:52 ` Tetsuo Handa
2018-11-23 12:52 ` Petr Mladek [this message]
2018-11-09 14:08 ` Linus Torvalds
2018-11-09 14:42 ` Steven Rostedt
2018-11-08 11:53 ` Petr Mladek
2018-11-08 12:44 ` Sergey Senozhatsky
2018-11-08 14:21 ` Sergey Senozhatsky
2018-11-09 9:54 ` Tetsuo Handa
2018-11-02 14:40 ` [PATCH v6 1/3] printk: Add line-buffered printk() API Matthew Wilcox
2018-11-03 1:55 ` Tetsuo Handa
2018-11-02 18:12 ` kbuild test robot
2018-11-06 14:35 ` Sergey Senozhatsky
2018-11-07 10:21 ` Petr Mladek
2018-11-07 12:54 ` Tetsuo Handa
2018-11-08 2:21 ` Sergey Senozhatsky
2018-11-08 11:24 ` Petr Mladek
2018-11-08 11:46 ` Tetsuo Handa
2018-11-08 12:30 ` Sergey Senozhatsky
2018-11-09 14:10 ` Petr Mladek
2018-11-12 7:59 ` Sergey Senozhatsky
2018-11-12 10:42 ` Tetsuo Handa
2018-11-17 10:14 ` Tetsuo Handa
2018-11-07 10:52 ` Tetsuo Handa
2018-11-07 11:01 ` David Laight
2018-11-07 12:00 ` Petr Mladek
2018-11-07 11:45 ` Petr Mladek
2018-11-08 2:30 ` Sergey Senozhatsky
2018-11-07 13:41 ` Petr Mladek
2018-11-07 14:06 ` Petr Mladek
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=20181123125219.k5flkypofll7jwtr@pathway.suse.cz \
--to=pmladek@suse.com \
--cc=akpm@linux-foundation.org \
--cc=dvyukov@google.com \
--cc=fengguang.wu@intel.com \
--cc=glider@google.com \
--cc=jpoimboe@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mingo@redhat.com \
--cc=penguin-kernel@i-love.sakura.ne.jp \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=sergey.senozhatsky.work@gmail.com \
--cc=sergey.senozhatsky@gmail.com \
--cc=torvalds@linux-foundation.org \
--cc=will.deacon@arm.com \
/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;
as well as URLs for NNTP newsgroup(s).