From: Hannes Reinecke <hare@suse.com>
To: ksummit-discuss@lists.linuxfoundation.org
Subject: Re: [Ksummit-discuss] [TECH TOPIC] printk redesign
Date: Mon, 19 Jun 2017 08:22:13 +0200 [thread overview]
Message-ID: <ef18231f-c69b-5d88-0410-485cfcf4143b@suse.com> (raw)
In-Reply-To: <20170619052146.GA2889@jagdpanzerIV.localdomain>
On 06/19/2017 07:21 AM, Sergey Senozhatsky wrote:
> Hello,
>
> I, Petr Mladek and Steven Rostedt would like to propose a printk
> tech topic (as suggested by Steven). We are currently exploring the idea
> of complete redesign and rework of printk and it would be extremely helpful
> to hear from the community. printk serves different purposes, and some of
> requirements of printk tend to contradict each other; printk is monolithic
> and quite heavy, no wonder, it causes problems sometimes.
>
> So the questions are (a short list) - what the new printk should be?
> should it remain monolithic, or can we split it? (e.g. core kernel messages
> don't share the log buffer with debug/info messages, etc.) what are the
> printk requirements? I've started playing with the idea of moving printk to
> per-CPU model: log buffers, per-CPU printk flusher threads. does is it make
> sense (wrt to printk requirements) to have direct and in-direct flushers of
> printk messages (e.g. core kernel messages are printed directly; debug/info
> messages are printed by printing kthreads, etc. well, unless in panic)? ...
>
> There are many other questions, so it'd be great to have a
> brainstorming session.
>
I'm all for it.
Personally, I'd love to see the printk mechanism split into something
which can be used primarily for logging/debugging (ie slow,
non-critical, large messages) and emergency messaging (ie fast, direct
messages like kernel oops and KERN_EMERG thingies).
Plus I'd love to decouple the message generation (ie writing into the
message log) from message output (ie printing out the message log).
That currently is a major performance drag when using slow output
devices like serial console.
Cheers,
Hannes
--
Dr. Hannes Reinecke Teamlead Storage & Networking
hare@suse.com +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
next prev parent reply other threads:[~2017-06-19 6:22 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-19 5:21 Sergey Senozhatsky
2017-06-19 6:22 ` Hannes Reinecke [this message]
2017-06-19 14:39 ` Steven Rostedt
2017-06-19 15:20 ` Andrew Lunn
2017-06-19 15:54 ` Hannes Reinecke
2017-06-19 16:17 ` Andrew Lunn
2017-06-19 16:23 ` Mark Brown
2017-06-20 15:58 ` Sergey Senozhatsky
2017-06-20 16:44 ` Luck, Tony
2017-06-20 17:11 ` Sergey Senozhatsky
2017-06-20 17:27 ` Mark Brown
2017-06-20 23:28 ` Steven Rostedt
2017-06-21 7:17 ` Hannes Reinecke
2017-06-21 11:12 ` Sergey Senozhatsky
2017-06-22 14:06 ` Steven Rostedt
2017-06-23 5:43 ` Sergey Senozhatsky
2017-06-23 13:09 ` Steven Rostedt
2017-06-21 12:23 ` Petr Mladek
2017-06-21 14:18 ` Andrew Lunn
2017-06-23 8:46 ` Petr Mladek
2017-06-21 16:09 ` Andrew Lunn
2017-06-23 8:49 ` Petr Mladek
2017-07-19 7:35 ` David Woodhouse
2017-07-20 7:53 ` Sergey Senozhatsky
2017-06-20 16:09 ` Sergey Senozhatsky
2017-06-19 16:26 ` Steven Rostedt
2017-06-19 16:35 ` Andrew Lunn
2017-06-24 11:14 ` Mauro Carvalho Chehab
2017-06-24 14:06 ` Andrew Lunn
2017-06-24 22:42 ` Steven Rostedt
2017-06-24 23:21 ` Andrew Lunn
2017-06-24 23:26 ` Linus Torvalds
2017-06-24 23:40 ` Steven Rostedt
2017-06-26 11:16 ` Sergey Senozhatsky
2017-06-24 23:48 ` Al Viro
2017-06-25 1:29 ` Andrew Lunn
2017-06-25 2:41 ` Linus Torvalds
2017-06-26 8:46 ` Jiri Kosina
2017-07-19 7:59 ` David Woodhouse
2017-06-20 15:56 ` Sergey Senozhatsky
2017-06-20 18:45 ` Daniel Vetter
2017-06-21 9:29 ` Petr Mladek
2017-06-21 10:15 ` Sergey Senozhatsky
2017-06-22 13:42 ` Daniel Vetter
2017-06-22 13:48 ` Daniel Vetter
2017-06-23 9:07 ` Bartlomiej Zolnierkiewicz
2017-06-27 13:06 ` Sergey Senozhatsky
2017-06-23 5:20 ` Sergey Senozhatsky
2017-06-19 23:46 ` Josh Triplett
2017-06-20 8:24 ` Arnd Bergmann
2017-06-20 14:36 ` Steven Rostedt
2017-06-20 15:26 ` Sergey Senozhatsky
2017-06-22 16:35 ` David Howells
2017-07-19 6:24 ` Sergey Senozhatsky
2017-07-19 6:25 ` Sergey Senozhatsky
2017-07-19 7:26 ` Daniel Vetter
2017-07-20 5:19 ` Sergey Senozhatsky
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=ef18231f-c69b-5d88-0410-485cfcf4143b@suse.com \
--to=hare@suse.com \
--cc=ksummit-discuss@lists.linuxfoundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox