Red Hat Bugzilla – Bug 457413
box OOM's under heavy mmap usage.
Last modified: 2013-01-09 16:22:35 EST
+++ This bug was initially created as a clone of Bug #457411 +++ While investigating a locking order bug that resulted in a hang (bz 439548) it was discovered that when the locking bug was fixed and the testcase was able to continue that it would cause an OOM kill. This problem is reproduceable upstream. The testcase is simple, untar it, edit the VAR file to point at a blank partition/volume that it will use, and then do sh run.sh and it will start, at some point you will see things getting killed. I'm also attaching a txt file with a sample of the OOM messages I got (on an upstream kernel). -- Additional comment from jbacik@redhat.com on 2008-07-31 10:52 EST -- Created an attachment (id=313105) reproducer -- Additional comment from jbacik@redhat.com on 2008-07-31 10:53 EST -- Created an attachment (id=313106) oom messages
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux major release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Major release. This request is not yet committed for inclusion.
The test case (modified a little to run in my 1GB RAM virtual machine) has been running for the past 2 hours. So far the VM seems unimpressed with the load :) It helps that the mlocked pages are moved onto the unevictable list and the page cache and anonymous pages are both on their own lists. Not having the 2/3 of memory that is mlocked getting in the way of the pageout scan really helps...
After 7 hours of run time, the system is still doing fine. I'll leave it running for several more days, but don't expect that RHEL 6 will need a fix for this issue.
I guess I forgot to change the BZ status. The bug appears to be fixed in RHEL 6 :)