page allocation failures, now in 2.6.38

page allocation failures, now in 2.6.38

[Mikael Abrahamsson]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2307 bytes --]


Hello.

I just upgraded my ubuntu 10.10 amd64 (2.6.35) to 11.04 (2.6.38) and 14 
hours after the upgrade, it oopsed related to nf_conntrak (I've sent an 
email to netdev about it). I don't know if it's related, but my page 
allocation failures have returned (I've had them quite a lot in the past) 
so I thought I'd report them again now that I'm running a newer kernel.

2.6.38-11-generic #50-Ubuntu SMP Mon Sep 12 21:17:25 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux

Oct  1 22:45:19 ub kernel: [38857.002540] __alloc_pages_slowpath: 12 callbacks suppressed
Oct  1 22:45:19 ub kernel: [38857.002545] swapper: page allocation failure. order:0, mode:0x4020
Oct  1 22:45:19 ub kernel: [38857.002551] Pid: 0, comm: swapper Tainted: G          I 2.6.38-11-generic #50-Ubuntu
Oct  1 22:45:19 ub kernel: [38857.002555] Call Trace:
Oct  1 22:45:19 ub kernel: [38857.002558]  <IRQ>  [<ffffffff811147e4>] ? __alloc_pages_nodemask+0x604/0x840
Oct  1 22:45:19 ub kernel: [38857.002577]  [<ffffffff81149f85>] ? alloc_pages_current+0xa5/0x110
Oct  1 22:45:19 ub kernel: [38857.002583]  [<ffffffff81153762>] ? new_slab+0x282/0x290
Oct  1 22:45:19 ub kernel: [38857.002589]  [<ffffffff81155222>] ? __slab_alloc+0x262/0x390
Oct  1 22:45:19 ub kernel: [38857.002597]  [<ffffffff814c6134>] ? __netdev_alloc_skb+0x24/0x50
Oct  1 22:45:19 ub kernel: [38857.002603]  [<ffffffff8115852b>] ? __kmalloc_node_track_caller+0x9b/0x1a0
Oct  1 22:45:19 ub kernel: [38857.002609]  [<ffffffff814c6134>] ? __netdev_alloc_skb+0x24/0x50
Oct  1 22:45:19 ub kernel: [38857.002615]  [<ffffffff814c5b93>] ? __alloc_skb+0x83/0x170
Oct  1 22:45:19 ub kernel: [38857.002620]  [<ffffffff814c6134>] ? __netdev_alloc_skb+0x24/0x50

Please see attached file for all the page allocation failures I got 
yesterday.

On 2.6.35, the failures seem to have been helped by 
"vm.min_free_kbytes=4096" but not anymore it seems. I just now changed it 
to 65536 just as a preventive measure.

The machine has most just disk cache, actual program memory usage is very 
light:

$ free
              total       used       free     shared    buffers     cached
Mem:       7992352    7866512     125840          0     160472    6785656
-/+ buffers/cache:     920384    7071968
Swap:            0          0          0


-- 
Mikael Abrahamsson    email: swmike@swm.pp.se

[-- Attachment #2: Type: APPLICATION/octet-stream, Size: 21073 bytes --]