lkml.org 
[lkml]   [2016]   [Mar]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RFC][PATCH v2 1/2] printk: Make printk() completely async
From
Date
Jan Kara wrote:
> > So for UP systems, we should by default disable async printing anyway I
> > suppose. It is just a pointless overhead. So please just make printk_sync
> > default to true if !CONFIG_SMP.
> >
> > When IRQs are disabled, you're right we will have a change in behavior. I
> > don't see an easy way of avoiding delaying of printk until IRQs get
> > enabled. I don't want to queue work directly because that creates
> > possibility for lock recursion in queue_work(). And playing some tricks
> > with irq_works isn't easy either - you cannot actually rely on any other
> > CPU doing anything (even a timer tick) because of NOHZ.
> >
> > So if this will be a problem in practice, using a kthread will probably be
> > the easiest solution.
>
> Hum, and thinking more about it: Considering that WQ_MEM_RECLAIM workqueues
> create kthread anyway as a rescuer thread, it may be the simplest to just
> go back to using a single kthread for printing. What do you think?
>

I think a plain kthread is better. printing_work_func() can become a buggy
function. console_unlock() from printing_work_func() can occupy kworker for
many seconds due to looping with cond_resched() (i.e. without calling
schedule_timeout_*()) from schedulable context which can in turn defer
other work items.

\
 
 \ /
  Last update: 2016-03-07 14:21    [W:0.068 / U:0.036 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site