Bug 169761 - oom_kill invoked under light vm load with swappiness=0
oom_kill invoked under light vm load with swappiness=0
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
i686 Linux
medium Severity low
: ---
: ---
Assigned To: Dave Jones
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2005-10-03 06:45 EDT by Mike Fedyk
Modified: 2015-01-04 17:22 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-10-05 18:39:29 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Just mozilla with a background bittorrent and swappiness=15 (12.74 KB, text/plain)
2005-10-05 02:47 EDT, Mike Fedyk
no flags Details

  None (edit)
Description Mike Fedyk 2005-10-03 06:45:44 EDT
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):

How reproducible:

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.

3. OOmkill

Actual Results:  OOMkill invoked

Expected Results:  Swap when needed instead of invoking oomkiller with lots of swap available.

Additional info:

oom-killer: gfp_mask=0x80d2, order=0
DMA per-cpu:
cpu 0 hot: low 2, high 6, batch 1 used:3
cpu 0 cold: low 0, high 2, batch 1 used:1
Normal per-cpu:
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
HighMem: empty
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).
Comment 1 Dave Jones 2005-10-03 18:08:03 EDT
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'.
Comment 2 Mike Fedyk 2005-10-04 23:42:42 EDT
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
Comment 3 Mike Fedyk 2005-10-05 02:47:44 EDT
Created attachment 119635 [details]
Just mozilla with a background bittorrent and swappiness=15
Comment 4 Dave Jones 2005-10-05 18:39:29 EDT
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
DMA zone.

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.
Comment 5 Mike Fedyk 2005-10-06 05:54:50 EDT
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...
Comment 6 Dave Jones 2005-10-06 16:07:57 EDT
fwiw, the fedora VM is 1:1 with upstream, so if you believe its doing the wrong
thing, the upstream vm developers at linux-kernel@vger.kernel.org may be interested.

Note You need to log in before you can comment on or make changes to this bug.