lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.02.1407021623380.5931@chino.kir.corp.google.com>
Date:	Wed, 2 Jul 2014 16:30:05 -0700 (PDT)
From:	David Rientjes <rientjes@...gle.com>
To:	Peter Zijlstra <peterz@...radead.org>
cc:	Stephane Eranian <eranian@...gle.com>,
	Paul Mackerras <paulus@...ba.org>,
	Ingo Molnar <mingo@...hat.com>,
	Arnaldo Carvalho de Melo <acme@...nel.org>,
	x86 <x86@...nel.org>, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [patch] x86, perf: avoid spamming kernel log for bts buffer
 failure

On Wed, 2 Jul 2014, Peter Zijlstra wrote:

> > David and I discussed this. He can probably add more background
> > info, if needed.
> 
> It would still be good to see why compaction etc is failing.
> 

"Why compaction is failing" has been the story of my life for the past few 
weeks, unfortunately.  One person ran into this and here is the breakdown 
at the time of the page allocation failure:

Node 0 DMA32: 12478*4kB 7595*8kB 2087*16kB 26*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 144896kB
Node 0 Normal: 55037*4kB 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 1*2048kB 0*4096kB = 222196kB
Node 1 Normal: 165860*4kB 18*8kB 1*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 663600kB

So we really don't have any order-4 or higher memory and if compaction and 
reclaim fails, then the allocation failure is printed every time.  This is 
what the patch is trying to address and we can't guarantee order-4 is 
always allocatable even with GFP_KERNEL.  This allocation is just outside 
the PAGE_ALLOC_COSTLY_ORDER == 3 threshold that would have oom killed 
something and retried; the oom killer is deferred for this case because 
there's no guarantee killing a process would have resulted in order-4 
memory being available (and nobody wants killing when they are 902MB above 
the per-zone min watermarks like this poor guy).
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ