Re: [Ksummit-discuss] [TECH TOPIC] printk redesign

[Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>]

On (06/22/17 10:06), Steven Rostedt wrote:
> On Wed, 21 Jun 2017 20:12:10 +0900
> Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> wrote:
>
> > I thought about it, and the question is:
> > would lockless per-CPU logbuffers buy us anything? we used to have
> 
> Well, I'm not 100% happy with the current NMI approach.

that's a good point.

> There is still no "print everything" from NMI. That is, prints from NMI
> must be placed in a buffer before going out, and that limits how much
> can be printed. And an ftrace_dump_on_oops can be huge.

hm, ok.

_just thinking out loud_

currently we've got a _very_ accidental fix/hack that lets us to bypass
printk_nmi per-CPU buffers in most of the cases and print NMI messages
directly to the logbuf, with the only exceptional case (when we store the
messages to the per-CPU printk_nmi buffer) being the case when NMI printk
happens on the CPU that owned the logbuf_lock at the time when NMI occurred
on that CPU. which is may be narrow enough. so we can keep printk_nmi and
printk_safe per-CPU buffers relatively small in size, and instead make
only logbuf really huge. with per-CPU logbufs design we would need to make
each CPU's buffer huge unconditionally.

but, at the same time, with the current implementation, there is a
possibility that we will have to make both logbuf and per-CPU buffers
really huge.

	-ss