On Mon 2017-12-18 14:31:01, Petr Mladek wrote: > On Mon 2017-12-18 18:36:15, Sergey Senozhatsky wrote: > > - it has a significantly worse behaviour compared to old async printk. > > - it keeps sleeping on console_sem tasks in TASK_UNINTERRUPTIBLE > > for a long time. > > - it timeouts user space apps. > > - it re-introduces the lockup vector, by passing console_sem ownership > > to atomic tasks. > > All this is in the current upstream code as well. Steven's patch > should make it better in compare with the current upstream code. > > Sure, the printk offload approach does all these things better. > But there is still the fear that the offload is not reliable > in all situations. The lazy offload should handle this well from > my POV but I am not 100% sure.
BTW: There is one interesting thing. If we rely on the kthread to handle flood of messages. It might be too slow because it reschedules. It might cause loosing messages. Note that the kthread should have rather normal priority to avoid blocking other processes. >From this point of view. We get the messages out much faster in an atomic context. The question is if we want to sacrifice the atomic context of a random process for this. Just an idea. The handshake + throttling big sinners might help to balance the load over the biggest sinners (printk users). The nice think about the hand-shake + throttling based approach is that it might be built step by step. Each step would just make things better. While the offloading is rather a big revolution. We already have many extra patches to avoid regressions in the reliability. One thing is that we play with offloading for years. The handshake might have problems that we just do not know about at the moment. But it definitely has some interesting aspects. Best Regards, Petr
