lkml.org 
[lkml]   [2005]   [Feb]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: swapper: page allocation failure. order:1, mode:0x20
Robert Hancock wrote:

> Bernd Schubert wrote:
>
>> Oh no, not this page allocation problems again. In summer I already
>> posted problems with page allocation errors with 2.6.7, but to me it
>> seemed that nobody cared. That time we got those problems every
>> morning during the cron jobs and our main file server always
>> completely crashed.
>> This time its our cluster master system and first happend after an
>> uptime of 89 days, kernel is 2.6.9. Besides of those messages, the
>> system still seems to run stable
>>
>> I really beg for help here, so please please please help me solving
>> this probem. What can I do to solve it?
>>

You should upgrade to the newest kernel if possible. If that's not possible,
increase /proc/sys/vm/min_free_kbytes

This allocation failure really should not cause your system to crash, but
increasing min_free_kbytes will make it less likely that you will see an
allocation failure.

>> First a (dumb) question, what does 'page allocation failure' really
>> mean? Is it some out of memory case?
>> Feb 28 10:04:45 hitchcock kernel: swapper: page allocation failure.
>> order:1, mode:0x20
>> Feb 28 10:04:45 hitchcock kernel:
>> Feb 28 10:04:45 hitchcock kernel: Call Trace:<IRQ>
>> <ffffffff8015b0de>{__alloc_pages+878}
>> <ffffffff8015b10e>{__get_free_pages+14}
>> Feb 28 10:04:45 hitchcock kernel:
>> <ffffffff8015edc6>{kmem_getpages+38}
>> <ffffffff803d064a>{ip_frag_create+26}
>> Feb 28 10:04:45 hitchcock kernel:
>> <ffffffff8016061e>{cache_grow+190}
>> <ffffffff80160e80>{cache_alloc_refill+560}
>> Feb 28 10:04:45 hitchcock kernel:
>> <ffffffff801617e3>{__kmalloc+195} <ffffffff803b5680>{alloc_skb+64}
>> Feb 28 10:04:45 hitchcock kernel:
>> <ffffffff8031727e>{tg3_alloc_rx_skb+222} <ffffffff80317553>{tg3_rx+371}
>> Feb 28 10:04:45 hitchcock kernel:
>> <ffffffff80317977>{tg3_poll+183} <ffffffff803bc306>{net_rx_action+134}
>
>
> Essentially the tg3 Ethernet driver is trying to allocate memory to
> store a received packet, and is unable to do so. Since this is done
> inside interrupt context, this allocation has to be serviced from
> physical memory. Order 1 means it only wanted one page of memory, and
> since that failed it looks like the system must have been awfully
> short on available physical RAM.. it could be some kind of kernel
> memory leak or VM issue, though this condition may not be entirely
> unexpected in certain cases, like if the system has little physical
> RAM free at a certain point and then a flood of network packets arrive.
>

Yep. The reason why these failures are beeing seen is that earlier
kernels did
not reserve enough memory for GFP_ATOMIC allocations. Later kernels
increased
this, and also made higher order (ie. greater than 0) GFP_ATOMIC allocations
more robust.



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

\
 
 \ /
  Last update: 2005-03-22 14:10    [W:0.057 / U:0.460 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site