Message-ID: <4EA51210.9070209@profihost.ag>
Date:	Mon, 24 Oct 2011 09:21:52 +0200
From:	Philipp Herz - Profihost AG <p.herz@...fihost.ag>
To:	Eric Dumazet <eric.dumazet@...il.com>
CC:	David Rientjes <rientjes@...gle.com>,
	Andi Kleen <andi@...stfloor.org>, s.priebe@...fihost.ag,
	linux-kernel@...r.kernel.org
Subject: Re: Vanilla-Kernel 3 - page allocation failure

Am 24.10.2011 09:03, schrieb Eric Dumazet:
> Le lundi 24 octobre 2011 à 08:33 +0200, Philipp Herz - Profihost AG a
> écrit :
>> Am 19.10.2011 03:58, schrieb David Rientjes:
>>> 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.
>>
>> Hi David,
>>
>> we have recompiled the kernel of one machine with CONFIG_SLUB instead of
>> CONFIG_SLAB, but it is showing similar message.
>>
>> Now it's showing failure at "order:5, mode:0x4020".
>>
>> Call trace can be found at:
>> * http://pastebin.com/uGJiwvG1
>>
>> Comparing kernel 2.6.32 (mm/page_alloc.c) there seams to be the same way
>> of dealing with page allocation.
>>
>> Do you have an idea why these (warning) messages do never appear running
>> 2.6.32?
>
> Your tg3 has a firmware limitation, and some skbs using fragments have
> to be reallocated using a single and contiguous area of memory.
>
> Initial skb delivered by tcp stack only uses order-0 pages, but the
> reallocated one, being 64K, can be order-5
>
> You can avoid this by following tuning :
>
> ethtool -K eth0 sg off
>

ok,

does that mean that there was no firmware limitation with kernel 2.6.32 
or that the tg3 module has any "disable warnings" flag matching 
__GFP_NOWARN?

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