Re: [PATCH] mm/page_alloc: Wait for oom_lock before retrying.

[Petr Mladek <pmladek@suse.com>]

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@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>