linux-kernel - Re: Vanilla-Kernel 3 - page allocation failure

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.00.1110181848150.12850@chino.kir.corp.google.com>
Date:	Tue, 18 Oct 2011 18:58:21 -0700 (PDT)
From:	David Rientjes <rientjes@...gle.com>
To:	Andi Kleen <andi@...stfloor.org>
cc:	p.herz@...fihost.ag, linux-kernel@...r.kernel.org
Subject: Re: Vanilla-Kernel 3 - page allocation failure

On Tue, 18 Oct 2011, Andi Kleen wrote:

> Philipp Herz - Profihost AG <p.herz@...fihost.ag> writes:
> 
> > After updating kernel (x86_64) to stable version 3 there are a few
> > messages appearing in the kernel log such as
> >
> > kworker/0:1: page allocation failure: order:1, mode:0x20
> > mysql: page allocation failure: order:1, mode:0x20
> > php5: page allocation failure: order:1, mode:0x20
> 
> You just ran out of memory.
> 

He ran out of order-1 physically contiguous memory and was unable to 
compact or reclaim because of the atomic context.

Philipp, based on your pastes from another post, it's evident you're using 
CONFIG_SLAB and, unfortunately, it's not possible to change to single 
page allocations (which would only result in a page allocation failure if 
you were completely out of memory) without recompiling.

You have a couple options:

 - recompile with BREAK_GFP_ORDER_HI redefined to 0 in mm/slab.c, or

 - recompile with CONFIG_SLUB instead of CONFIG_SLAB.

It's very possible that neither of these will help, but it will tell you 
whether you need to go out and buy more RAM or not.  If you try to 
recompile with BREAK_GFP_ORDER_HI, these may turn into order-0 
allocations.  If you can't reboot, send the output of 
/proc/<pid>/net/protocols where <pid> is the pid of one of the above tasks 
(kworker, mysql, php5) when they are running and we'll know.

 [ Changing slab_break_gfp_order should really be a CONFIG_SLAB command-
   line option.  It can't be runtime because slab depends on the order for
   caches remaining constant, but we can certainly change it on boot. ]

If you try CONFIG_SLUB instead of CONFIG_SLAB, you can pass 
slub_max_order=0 on the command line and see if it helps.
--
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/