Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1404806 > unrolled thread

Re: zone_reclaimable() leads to livelock in __alloc_pages_slowpath()

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: zone_reclaimable() leads to livelock in __alloc_pages_slowpath() Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> - 2016-05-21 06:10 +0200
    Re: zone_reclaimable() leads to livelock in __alloc_pages_slowpath() Oleg Nesterov <oleg@redhat.com> - 2016-05-22 23:20 +0200

#1404806 — Re: zone_reclaimable() leads to livelock in __alloc_pages_slowpath()

On 2016/05/21 5:28, Oleg Nesterov wrote:
> Hello,
> 
> Recently I hit the problem, _sometimes_ the system just hangs in OOM situation.
> Surprisingly, this time OOM-killer is innocent ;) and finally I can reproduce
> this more-or-less reliably just running
> 
> 	#include <stdlib.h>
> 	#include <string.h>
> 
> 	int main(void)
> 	{
> 		for (;;) {
> 			void *p = malloc(1024 * 1024);
> 			memset(p, 0, 1024 * 1024);
> 		}
> 	}
> 
> in a loop on the otherwise idle system. 512m RAM, one CPU (but CONFIG_SMP=y),
> no swap, and only one user-space process (apart from test-case above), /bin/sh
> runnning as init with pid==1. I am attaching my .config just in case, but I
> think the problem is not really specific to this configuration.
> 
> --------------------------------------------------------------------------------
> It spins in __alloc_pages_slowpath() forever, __alloc_pages_may_oom() is never
> called, it doesn't react to SIGKILL, etc.
> 
> This is because zone_reclaimable() is always true in shrink_zones(), and the
> problem goes away if I comment out this code
> 
> 	if (global_reclaim(sc) &&
> 	    !reclaimable && zone_reclaimable(zone))
> 		reclaimable = true;
> 
> in shrink_zones() which otherwise returns this "true" every time, and thus
> __alloc_pages_slowpath() always sees did_some_progress != 0.
> 

Michal Hocko's OOM detection rework patchset that removes that code was sent
to Linus 4 hours ago. ( https://marc.info/?l=linux-mm-commits&m=146378862415399 )
Please wait for a few days and try reproducing using linux.git .

[toc] | [next] | [standalone]

#1405047

On 05/21, Tetsuo Handa wrote:
>
> On 2016/05/21 5:28, Oleg Nesterov wrote:
> > It spins in __alloc_pages_slowpath() forever, __alloc_pages_may_oom() is never
> > called, it doesn't react to SIGKILL, etc.
> >
> > This is because zone_reclaimable() is always true in shrink_zones(), and the
> > problem goes away if I comment out this code
> >
> > 	if (global_reclaim(sc) &&
> > 	    !reclaimable && zone_reclaimable(zone))
> > 		reclaimable = true;
> >
> > in shrink_zones() which otherwise returns this "true" every time, and thus
> > __alloc_pages_slowpath() always sees did_some_progress != 0.
> >
>
> Michal Hocko's OOM detection rework patchset that removes that code was sent
> to Linus 4 hours ago. ( https://marc.info/?l=linux-mm-commits&m=146378862415399 )
> Please wait for a few days and try reproducing using linux.git .

I guess you mean
http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/mm/vmscan.c?id=fa8c5f033ebb43f925d68c29d297bafd36af7114
"mm, oom: rework oom detection"...

Yes thanks a lot Tetsuo, it should fix the problem.

Cough I can't resist I hate Michal^W the fact this was already fixed ;) Because
it took me some time to understand whats going on, initially it looked like some
subtle and hard-to-reproduce bug in userfaultfd.

Thanks!

Oleg.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web