[Ksummit-discuss] [TECH TOPIC] printk redesign
Andrew Lunn
andrew at lunn.ch
Wed Jun 21 14:18:08 UTC 2017
On Wed, Jun 21, 2017 at 02:23:04PM +0200, Petr Mladek wrote:
> On Tue 2017-06-20 19:28:58, Steven Rostedt wrote:
> > I've thought about this a little too.
> >
> > I would like printk to have per-cpu buffers. Then we don't even need to
> > store the CPU number, that would be explicit by which buffer the data
> > is stored in.
> >
> > The one thing that is needed, is the consumer. In ftrace, it's whatever
> > reads the buffer, which is usually user space, but can be the kernel
> > (see sysctl-z). But there's only one consumer at a time.
> >
> > I was thinking about a new design for printk. Similar to ftrace, but
> > different.
> >
> > 1) have per cpu buffers, that are lockless. Writes happen immediately,
> > but the output happens later.
>
> My problems with per-CPU buffers is that:
>
> + I am not sure how big per-CPU buffers we could afford.
> Any non-balanced usage increases the chance of loosing
> messages.
>
> + The information is scattered and extra tools are needed
> to locate the messages and sort them.
Considering this from the Embedded world, during board bring up, you
might be poking around in memory using a JTAG interface because your
serial driver is not working yet, or the kernel is crashing before the
serial port is up and running. The in-memory format needs to be quite
simple to read. I don't know how early_printk() factors into
this. Maybe that solves this problem?
Andrew
More information about the Ksummit-discuss
mailing list