[Ksummit-discuss] [TECH TOPIC] printk redesign

Hannes Reinecke hare at suse.com
Mon Jun 19 06:22:13 UTC 2017


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 at 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)


More information about the Ksummit-discuss mailing list