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

[Sergey Senozhatsky <sergey.senozhatsky@gmail.com>]

On (12/14/16 12:01), Petr Mladek wrote:
> 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.

well, printk_deferred moves console_unlock() to IRQ context. so
we still have a classic lockup, other CPUs still can add messages
to logbuf, expect that now we are doing printing from IRQ (assuming
that IRQ work acquired the console sem). lockup in IRQ is worth
than softlockup. (well, just saying)


static void wake_up_klogd_work_func(struct irq_work *irq_work)
{
	if (console_trylock())
		console_unlock();
}

static DEFINE_PER_CPU(struct irq_work, wake_up_klogd_work) = {
	.func = wake_up_klogd_work_func,
	.flags = IRQ_WORK_LAZY,
};



> This is where async printk should help. And printk_deferred()
> is the way to use async printk for a particular printk call.

yes, with a difference that async printk does not work from IRQ.
I'm a bit lost here, sorry. do you mean async-printk/deferred
patch set from my tree or the current printk_deferred()?

	-ss

--
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>