[lkml]   [2011]   [Oct]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Vanilla-Kernel 3 - page allocation failure
On Tue, 18 Oct 2011, Andi Kleen wrote:

> Philipp Herz - Profihost 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.

 \ /
  Last update: 2011-10-19 04:03    [W:0.130 / U:1.932 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site