On (12/14/16 11:26), Michal Hocko wrote: > On Wed 14-12-16 10:37:06, Petr Mladek wrote: > > On Tue 2016-12-13 21:06:57, Tetsuo Handa wrote: > [...] > > > Although it is fine to make warn_alloc() less verbose, this is not > > > a problem which can be avoided by simply reducing printk(). Unless > > > we give enough CPU time to the OOM killer and OOM victims, it is > > > trivial to lockup the system. > > > > You could try to use printk_deferred() in warn_alloc(). It will not > > handle console. > > the problem is, however, _any_ printk under the oom_lock. So all of them > would have to be converted AFAIU. > > > It will help to be sure that the blocked printk() > > is the main problem. > > I think we should rather ratelimit those messages than tweak the way how > the printk is used. The source of the heavy printk might be completely > different so this has to be addressed at the printk level. yes, rate limiting seems to be the only right thing to do. if not for lockup avoidance (async printk can help here), then for logbuf overflow and lost messages avoidance (async printk can't prevent this from happening). -ss -- 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>