page allocation failure & sk98lin

page allocation failure & sk98lin

[Serban Simu]

Hello all,

I found a few references to similar problems in the list but no 
indications of whether this has been fixed or can be avoided.

I'm using 2.6.8.1 and the patch: sk98lin_v7.04_2.6.8_patch. This happens 
  when receiving data fast on the GigE card (about 600Mbps) and writing 
on disk. It seems to happen after writing 1 GB to disk (1024 MB) but I 
can't correlate that very reliably.

I would appreciate any information pointing me to a fix or explanation.

Thank you!

-Serban

swapper: page allocation failure. order:0, mode:0x20
  [<c013ec91>] __alloc_pages+0x2bf/0x2dd
  [<c013ecc7>] __get_free_pages+0x18/0x24
  [<c0141b8a>] kmem_getpages+0x20/0xc9
  [<c01427b3>] cache_grow+0xae/0x156
  [<c0142a2f>] cache_alloc_refill+0x1d4/0x211
  [<c0142e50>] __kmalloc+0x79/0x8c
  [<c027bd63>] alloc_skb+0x35/0xc9
  [<f8b7cbc4>] AllocAndMapRxBuffer+0x1e/0xc1 [sk98lin]
  [<f8b7af5a>] GiveRxBufferToHw+0x14e/0x3f4 [sk98lin]
  [<f8b7b274>] FillReceiveTableYukon2+0x74/0x7c [sk98lin]
  [<f8b7c467>] HandleStatusLEs+0xd4/0x30e [sk98lin]
  [<f8b7aa5f>] SkY2Poll+0x33/0xed [sk98lin]
  [<c02817cf>] net_rx_action+0x70/0xf2
  [<c0124fa2>] __do_softirq+0x52/0xab
  [<c0125028>] do_softirq+0x2d/0x2f
  [<c0107f9e>] do_IRQ+0xfb/0x112
  [<c01066d8>] common_interrupt+0x18/0x20
  [<c01040da>] mwait_idle+0x25/0x4a
  [<c01040a7>] cpu_idle+0x2e/0x3c
  [<c01216d5>] call_console_drivers+0xce/0xeb
  [<c01bb1b8>] vscnprintf+0x14/0x21
  [<c012191b>] printk+0x152/0x165

Re: page allocation failure & sk98lin

[Nick Piggin]

Serban Simu wrote:

> Hello all,
>
> I found a few references to similar problems in the list but no 
> indications of whether this has been fixed or can be avoided.
>
> I'm using 2.6.8.1 and the patch: sk98lin_v7.04_2.6.8_patch. This 
> happens  when receiving data fast on the GigE card (about 600Mbps) and 
> writing on disk. It seems to happen after writing 1 GB to disk (1024 
> MB) but I can't correlate that very reliably.
>
> I would appreciate any information pointing me to a fix or explanation.
>
> Thank you!
>
> -Serban
>
> swapper: page allocation failure. order:0, mode:0x20


The messages should be basically harmless and can't be completely avoided.

That said, -mm kernels have patches to fix up numerous problems with the 
page
allocator which have a good chance of fixing your problems.

Re: page allocation failure & sk98lin

[Serban Simu]

Thank you, Nick. Just wanted to mention that while I understand that we 
recover from this allocation failure (and also I don't mind the stack 
printouts), about 20% of my incoming network traffic (600-700 Mbps) 
seems to be dropped in the process. Does the memory manager have to 
spend a considerable amount of time to recover?

I will have a look at the -mm fixes, thanks for the idea.

-Serban

Nick Piggin wrote:

> Serban Simu wrote:
> 
>> Hello all,
>>
>> I found a few references to similar problems in the list but no 
>> indications of whether this has been fixed or can be avoided.
>>
>> I'm using 2.6.8.1 and the patch: sk98lin_v7.04_2.6.8_patch. This 
>> happens  when receiving data fast on the GigE card (about 600Mbps) and 
>> writing on disk. It seems to happen after writing 1 GB to disk (1024 
>> MB) but I can't correlate that very reliably.
>>
>> I would appreciate any information pointing me to a fix or explanation.
>>
>> Thank you!
>>
>> -Serban
>>
>> swapper: page allocation failure. order:0, mode:0x20
> 
> 
> 
> The messages should be basically harmless and can't be completely avoided.
> 
> That said, -mm kernels have patches to fix up numerous problems with the 
> page
> allocator which have a good chance of fixing your problems.
> -
> 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/
> 

Re: page allocation failure & sk98lin

[Nick Piggin]

Serban Simu wrote:
> Thank you, Nick. Just wanted to mention that while I understand that we 
> recover from this allocation failure (and also I don't mind the stack 
> printouts), about 20% of my incoming network traffic (600-700 Mbps) 
> seems to be dropped in the process.

Yeah that is expected - so I guess it isn't exactly 'harmless' if
performance is critical.

> Does the memory manager have to 
> spend a considerable amount of time to recover?
> 
> I will have a look at the -mm fixes, thanks for the idea.
> 

The relevant patch is this one which is now merged into 2.6.

http://linux.bkbits.net:8080/linux-2.5/cset@412b8828ClkE2ZwNwGQ02aYoMwb7-A?nav=index.html|ChangeSet@-1d

It would be nice if you can test that. It will give GFP_ATOMIC allocators
a larger buffer between starting memory reclaim, and failing their allocations.

However if it is a production system and you can't test patches, Marcelo
pointed out that you should be able to work around the problem by increasing
/proc/sys/vm/min_free_kbytes. Then maybe you could try 2.6.9 with min_free_kbytes
back to its default setting :)