On Tue 2017-07-11 15:49:00, Michal Hocko wrote: > On Tue 11-07-17 22:10:36, Tetsuo Handa wrote: > > Michal Hocko wrote: > > > On Mon 10-07-17 22:54:37, Tetsuo Handa wrote: > > > > What makes this situation worse is, since warn_alloc() periodically appends to > > > > printk() buffer, the thread inside the OOM killer with oom_lock held can stall > > > > forever due to cond_resched() from console_unlock() from printk(). > > > > > > warn_alloc is just yet-another-user of printk. We might have many > > > others... > because you are trying to address a problem at a wrong layer. If there > is absolutely no way around it and printk is unfixable then we really > need a printk variant which will make sure that no excessive waiting > will be involved. Then we can replace all printk in the oom path with > this special printk. The last theory about printk offloading suggests that printk() should always try to push some messages to the console when the console lock is available. Otherwise, the messages might not appear at all because the offloading is never 100% reliable, especially when the system is in troubles. In each case, this live-lock is another reason to risk the printk offload at some stage. Of course, we could make the throttling more aggressive. But it is another complex problem. Only printk() knows how much it is stressed and how much throttling is needed. On the other hand, it might be hard to know what information is repeating and who need to be throttled. It is a question if it should be solved by providing more printk_throttle() variants or by some magic inside normal printk(). 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>
