On Thu 2016-12-22 19:27:17, Tetsuo Handa wrote: > Sergey Senozhatsky wrote: > > On (12/19/16 21:27), Sergey Senozhatsky wrote: > > [..] > > > > > > I'll finish re-basing the patch set tomorrow. > > > > > > > pushed > > > > https://gitlab.com/senozhatsky/linux-next-ss/commits/printk-safe-deferred > > > > not tested. will test and send out the patch set tomorrow. > > > > -ss > > Thank you. I tried "[PATCHv6 0/7] printk: use printk_safe to handle printk() > recursive calls" at https://lkml.org/lkml/2016/12/21/232 on top of linux.git > as of commit 52bce91165e5f2db "splice: reinstate SIGPIPE/EPIPE handling", but > it turned out that your patch set does not solve this problem. > > I was assuming that sending to consoles from printk() is offloaded to a kernel > thread dedicated for that purpose, but your patch set does not do it. As a result, > somebody who called out_of_memory() is still preempted by other threads consuming > CPU time due to cond_resched() from console_unlock() as demonstrated by below patch. Ah, it was a misunderstanding. The "printk_safe" patchset allows to call printk() from inside some areas guarded by logbuf_lock. By other words, it allows to print errors from inside printk() code. I does not solve the soft-/live-locks. We need the async printk patchset here. It will allow to offload the console handling to the kthread. AFAIK, Sergey wanted to rebase it on top of the printk_safe patchset. I am not sure when he want or will have time to do so, though. Best Regards, Petr -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>