Re: [RFC][PATCHv3 2/5] printk: introduce printing kernel thread

[Petr Mladek]

On Wed 2017-05-31 16:30:59, Sergey Senozhatsky wrote:
> Hello Jan,
> 
> On (05/29/17 14:12), Jan Kara wrote:
> [..]
> > Actually I had something very similar in old versions of my patch set. And
> > it didn't work very well. The problem was that e.g. sometimes scheduler
> > decided that printk kthread should run on the same CPU as the process
> > currently doing printing and in such case printk kthread never took over
> > printing and the machine locked up due to heavy printing.
> 
> hm, interesting.
> 
> > > First, the real time priority is questionable on its own. Logging
> > > is important but the real time priority is dangerous. Any "flood"
> > > of messages will starve all other processes with normal priority.
> > > It is better than a softlockup but it might cause problems as well.
> > 
> > Processes with real-time priority should have well bounded runtime (in
> > miliseconds). Printk kthread doesn't have such bounded runtime so it should
> > not be a real time process as it could hog the CPU it is running on...
> 
> yeah, I can easily make it a normal prio task. at the same time
> printk_kthread has 'soft' limits on its execution. it's under the
> same constraints as the rest of the processes that do printing.
> there can be a random RT task doing console_trylock()->console_unlock(),
> so we still can hog CPUs. but, yeah, I don't want printk_kthread to be
> special.

There is a difference. The only job of printk_kthread is to flush
messages to the console. It is scheduled as long as there
are pending messages. Any other RT task has other purpose. It stops
being scheduled when the other purpose is handled.

I am sorry if this was obvious after reading my other reply.

Best Regards,
Petr