On Wed 2016-12-14 19:20:28, Sergey Senozhatsky wrote: > On (12/14/16 10:37), Petr Mladek wrote: > [..] > > > ---------- > > > [ 450.767693] Out of memory: Kill process 14642 (a.out) score 999 or sacrifice child > > > [ 450.769974] Killed process 14642 (a.out) total-vm:4168kB, anon-rss:84kB, file-rss:0kB, shmem-rss:0kB > > > [ 450.776538] oom_reaper: reaped process 14642 (a.out), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB > > > [ 450.781170] Out of memory: Kill process 14643 (a.out) score 999 or sacrifice child > > > [ 450.783469] Killed process 14643 (a.out) total-vm:4168kB, anon-rss:84kB, file-rss:0kB, shmem-rss:0kB > > > [ 450.787912] oom_reaper: reaped process 14643 (a.out), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB > > > [ 450.792630] Out of memory: Kill process 14644 (a.out) score 999 or sacrifice child > > > [ 450.964031] a.out: page allocation stalls for 10014ms, order:0, mode:0x24280ca(GFP_HIGHUSER_MOVABLE|__GFP_ZERO) > > > [ 450.964033] CPU: 0 PID: 14622 Comm: a.out Tainted: G W 4.9.0+ #99 > > > (...snipped...) > > > [ 740.984902] a.out: page allocation stalls for 300003ms, order:0, mode:0x24280ca(GFP_HIGHUSER_MOVABLE|__GFP_ZERO) > > > [ 740.984905] CPU: 0 PID: 14622 Comm: a.out Tainted: G W 4.9.0+ #99 > > > ---------- > > > > > > 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. It will help to be sure that the blocked printk() > > is the main problem. > > I thought about deferred printk, but I'm afraid in the given > conditions this has great chances to badly lockup the system. I am just curious. Do you have any particular scenario in mind? AFAIK, the current problem is the classic softlockup in console_unlock(). Other CPUs are producing a flood of printk messages and the victim is blocked in console_unlock() "forever". I do not see any deadlock with logbuf_lock. This is where async printk should help. And printk_deferred() is the way to use async printk for a particular printk call. Did I miss something, please? 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>