All of lore.kernel.org
 help / color / mirror / Atom feed
From: Philipp Herz - Profihost AG <p.herz@profihost.ag>
To: Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Vanilla-Kernel 3 - page allocation failure
Date: Tue, 18 Oct 2011 14:07:38 +0200	[thread overview]
Message-ID: <4E9D6C0A.1030801@profihost.ag> (raw)
In-Reply-To: <20111018113251.GA3782@oc1711230544.ibm.com>

Hello Cascardo,

thanks for your detailed answer!

I have uploaded two call traces to pastebin for further investigation.

Maybe this can help you.

* http://pastebin.com/Psg2dGYC (kworker)
* http://pastebin.com/pPFjZqxL (php5)

Regards,
Philipp


Am 18.10.2011 13:32, schrieb Thadeu Lima de Souza Cascardo:
> On Tue, Oct 18, 2011 at 12:25:03PM +0200, Philipp Herz - Profihost AG wrote:
>> 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
>>
>> Searching the net showed that these messages are known to occur since 2004.
>>
>> Some people were able to get rid of them by setting
>> /proc/sys/vm/min_free_kbytes to a high enough value. This does not
>> help in our case.
>>
>>
>> Is there a kernel comand line argument to avoid these messages?
>>
>> As of mm/page_alloc.c these messages are marked to be only warning
>> messages and would not appear if 'gpf_mask' was set to __GFP_NOWARN
>> in function warn_alloc_failed.
>>
>> How does this mask get set? Is it set by the "external" process
>> knocking at the memory manager?
>>
>
> Hello, Philipp.
>
> This happens when kernel tries to allocate memory, sometimes in response
> to some request by the user space, but also in other contexts. For
> example, an interrupt by a network driver may try to allocate memory. In
> this context, it will use GFP_ATOMIC as a mask, for example. The most
> usual flags in the kernel are GFP_KERNEL and GFP_ATOMIC.
>
>> What is the magic behind the 'order' and 'mode'?
>>
>
> The order is the binary log of the number of pages requested. So, order 1
> allocations are 2 pages, order 4 would be 16 pages, for example.
>
> The mode is, in fact, gfp_flags. 0x20 is GFP_ATOMIC. This kind of
> allocation cannot do IO or access the filesystem. Also, it cannot wait
> for reclaim memory from cache.
>
> This warning is usually followed by some statistics about memory use
> in your system. Please post it to give more information about this
> situation.
>
> I have watched some of this happen when lots of cache is used by some
> filesystems. Perhaps, some tweaking of the vm sysctl options may help,
> but I can point any magic tweaking right now.
>
> Regards,
> Cascardo.
>
>> I'm not a subscriber, so please CC me a copy of messages related to
>> the subject. I'm not sure if I can help much by looking at the
>> inside of the kernel, but I will try my best to answer any questions
>> concerning this issue.
>>
>> Best regards, Philipp
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at  http://www.tux.org/lkml/
>

  reply	other threads:[~2011-10-18 12:07 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-18 10:25 Vanilla-Kernel 3 - page allocation failure Philipp Herz - Profihost AG
2011-10-18 11:32 ` Thadeu Lima de Souza Cascardo
2011-10-18 12:07   ` Philipp Herz - Profihost AG [this message]
2011-10-18 12:38     ` Thadeu Lima de Souza Cascardo
2011-10-18 13:24       ` Philipp Herz - Profihost AG
2011-10-18 14:35         ` Thadeu Lima de Souza Cascardo
2011-10-19  6:45           ` Philipp Herz - Profihost AG
2011-10-18 15:51 ` Andi Kleen
2011-10-18 17:02   ` Dave Jones
2011-10-18 18:59     ` Andi Kleen
2011-10-19  1:58   ` David Rientjes
2011-10-24  6:33     ` Philipp Herz - Profihost AG
2011-10-24  7:03       ` Eric Dumazet
2011-10-24  7:21         ` Philipp Herz - Profihost AG
2011-10-24  8:01           ` Eric Dumazet
2011-10-24  8:19             ` Philipp Herz - Profihost AG
2011-10-24  8:29               ` Eric Dumazet
2011-10-24  8:36                 ` Stefan Priebe - Profihost AG
2011-10-26 20:26       ` David Rientjes
2011-10-27  7:13         ` Philipp Herz - Profihost AG
2011-10-27 20:08           ` David Rientjes
2011-10-20 21:11   ` Valdis.Kletnieks
2011-10-21  6:36     ` Philipp Herz - Profihost AG
  -- strict thread matches above, loose matches on Subject: below --
2011-10-18 10:24 Philipp Herz - Profihost AG
2011-10-19  2:09 ` David Rientjes

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4E9D6C0A.1030801@profihost.ag \
    --to=p.herz@profihost.ag \
    --cc=cascardo@linux.vnet.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.