Re: [RFC PATCH] printk: Introduce "store now but print later" prefix.

[Sergey Senozhatsky]

On (03/04/19 15:23), Petr Mladek wrote:
> > I confirmed that printk_deferred() is not suitable for this purpose, for
> > it suddenly stalls for seconds at random locations flushing pending output
> > accumulated by printk_deferred(). Stalling inside critical section (e.g.
> > RCU read lock held) is what I don't like.
> 
> I still do not see why your async printk should be significantly
> better than printk_deferred(). There is still a random victim
> that would be responsible to flush the messages.
> 
> It might increase the chance that it will get printed from
> normal context. But it also adds the risk that consoles
> will not get handled at all.
> 
> BTW: The comment above printk_deferred() is there for a reason.
>      It is a hack that should not be used widely.
> 
>      If you convert half printk() calls into a deferred/async
>      module, you will just get into another problems. For example,
>      not seeing the messages at all, more lost messages, random
>      victims would spend even more time with flushing to the console.

The thing with printk_deferred/printk_safe is that it always involves
IRQ->console_unlock()->loop. This thing is not welcome, we need some
other task to hand off printing to badly or we simply hard lockup the
system. I'd say that this probably should be the main reason those
those symbols are not exported.

> For example, I would stop printing allocation failures until
> the currently running OOM killer succeeds in freeing some memory.
> It might print a message about that all further allocation
> failures will not get reported and then another message
> about the success...

I'm all for it.

	-ss