Red Hat Bugzilla – Bug 169761
oom_kill invoked under light vm load with swappiness=0
Last modified: 2015-01-04 17:22:28 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050922 Fedora/1.0.7-1.1.fc4 Firefox/1.0.7
Description of problem:
Running with swappiness=0 with firefox & gftp.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
Firefox is running and has ~5 tabs open.
1. Start upload of several files in gftp
2. run "yum list all > /tmp/yum.list"
Less than 1% of swap is used.
Actual Results: OOMkill invoked
Expected Results: Swap when needed instead of invoking oomkiller with lots of swap available.
oom-killer: gfp_mask=0x80d2, order=0
cpu 0 hot: low 2, high 6, batch 1 used:3
cpu 0 cold: low 0, high 2, batch 1 used:1
cpu 0 hot: low 62, high 186, batch 31 used:71
cpu 0 cold: low 0, high 62, batch 31 used:42
HighMem per-cpu: empty
Free pages: 3740kB (0kB HighMem)
Active:52388 inactive:1593 dirty:0 writeback:32 unstable:0 free:935 slab:6458 mapped:53001 pagetables:946
DMA free:1080kB min:124kB low:152kB high:184kB active:10256kB inactive:0kB present:16384kB pages_scanned:17988 all_unreclaimable? yes
lowmem_reserve: 0 239 239
Normal free:2660kB min:1916kB low:2392kB high:2872kB active:199296kB inactive:6372kB present:245564kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve: 0 0 0
HighMem free:0kB min:128kB low:160kB high:192kB active:0kB inactive:0kB present:0kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve: 0 0 0
DMA: 0*4kB 1*8kB 1*16kB 1*32kB 0*64kB 0*128kB 0*256kB 0*512kB 1*1024kB 0*2048kB 0*4096kB = 1080kB
Normal: 93*4kB 34*8kB 6*16kB 4*32kB 0*64kB 0*128kB 1*256kB 1*512kB 1*1024kB 0*2048kB 0*4096kB = 2660kB
Swap cache: add 311, delete 278, find 0/0, race 0+0
Free swap = 523036kB
Total swap = 524280kB
Free swap: 523036kB
65487 pages of RAM
0 pages of HIGHMEM
1837 reserved pages
60006 pages shared
33 pages swap cached
0 pages dirty
32 pages writeback
53001 pages mapped
6459 pages slab
946 pages pagetables
Out of Memory: Killed process 5661 (firefox-bin).
amount of memory, or amount of swap is irrelevant.
What's important is the _type_ of memory being requested.
In this case, a DMA allocation was requested, and yours is nearly exhausted (You
can't use every single page, or the system would lock up completely). DMA memory
isn't swappable, and there's not a lot of it (16MB).
64MB of RAM is pretty much asking for trouble if you try multitasking while
running a memory hog like firefox.
So, your 'normal' zone, is 48MB. Once you've used that, normal zone allocations
will fall back and start exhausting the DMA zone too.
There's no solution here other than 'buy more ram' or 'run less/smaller programs'.
Uhh, that is 256MB of ram. See:
Normal free:2660kB min:1916kB low:2392kB high:2872kB active:199296kB
inactive:6372kB present:245564kB pages_scanned:0 all_unreclaimable? no
Created attachment 119635 [details]
Just mozilla with a background bittorrent and swappiness=15
duh, I forgot to multiply the 65487 pages of ram by the page size.
The other oom kill reports are the same situation though, you've exhausted your
Despite my maths being off in the earlier example, the fundamentals remain -
firefox has a majority of your pages mapped, making further allocations have to
fall back to the DMA zone.
swappiness doesn't factor in here, because firefox is using those pages, so they
never fall off the active list, and don't get considered for paging out.
I disagree. I was running with swappiness=0 just fine before the 2.6.13 rebase.
That was with firefox, openoffice, bittorrent and bluefish running.
I will leave this bug closed until I go a couple weeks at swappiness=60 (the
default) for a few weeks without any oom_kills.
Also, I wouldn't be surprised if the vm pressure that swappiness adjusts also
affects the oom_kill algo...
fwiw, the fedora VM is 1:1 with upstream, so if you believe its doing the wrong
thing, the upstream vm developers at firstname.lastname@example.org may be interested.