[Bug 241048] After r349840, OOM reported when swap space is available.

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241048

            Bug ID: 241048
           Summary: After r349840, OOM reported when swap space is
                    available.
           Product: Base System
           Version: 11.2-STABLE
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Some People
          Priority: ---
         Component: kern
          Assignee: bugs at FreeBSD.org
          Reporter: rkoberman at gmail.com

After the MFC of base r349840 amd base r349841 to 12-STABLE as base r350374,
attempts to start a VirtualBox Windows7 guest would fail when there was memory
pressure forcing swapping. Another user running HEAD on an RPi3 with 6 GB of
RAM is reporting similar OOM issues, though his case is triggered by building
www/chromium. It does involve OOM with a lot of swap available and it appears
to not occur if r349840 and r349841 are rolled back. Just reverting base
r349841 does not resolve the issue.

Note that r349840 should do absolutely nothing on systems with less than 16 GB
of RAM. This is per the author, markj at . So far he has no explanation for the
problem.

My system is a Lenovo T520 with a Sandy Bridge processor, 8 GB of RAM and * GB
of swap space evenly spit over two drives. The amount of swap space in use
seems irrelevant ss the failure has occurred with over 7 GB of free swap space.
The failure never occurs when the free memory is adequate to start the VM
without swapping.

I have not looked at the code in VirtualBox to see how it allocates memory, but
I would guess that it uses slab allocation for loading the memory image (4 GB)
of the virtual machine. I suspect that it uses malloc for loading the VB
(VirtualBox) code. It looks like the load of the virtual machine's memory works
OK, as a minimum of 98% of the load always completes regardless of the amount
of swap required without problem. At 98%, the load percentage holds for several
seconds and then errors out. If there is no memory pressure, there is no pause
at 98%. If the VM is restarted, it succeeds with no pause.

An occasional non-fatal error is similar except that the pause may happen at
99% and a non-fatal error that the VM could not be started due to lack of
memory and applications should be terminated to free memory. The VM is left in
the paused (greyed out) state, but the system may be immediately "un-paused" 
and it runs instantly with no other action.

The other user, Bob Prohaske, provided information on his case and agreed to my
including a link to it in this PR. The files are at
http://www.zefox.net/~fbsd/rpi3/swaptests/oberman/ I am not attaching he logs
due to their size. They include logs of attempts to build chromium which
succeeds with r349839 and fails with r349841. Note that his system is running
HEAD.

-- 
You are receiving this mail because:
You are the assignee for the bug.