Date: Fri, 04 Oct 2019 02:15:12 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 241048] After r349840, OOM reported when swap space is available. Message-ID: <bug-241048-227@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D241048 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@FreeBSD.org Reporter: rkoberman@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 mem= ory 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 buildi= ng www/chromium. It does involve OOM with a lot of swap available and it appea= rs 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@. 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 sp= ace. 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 w= orks OK, as a minimum of 98% of the load always completes regardless of the amou= nt of swap required without problem. At 98%, the load percentage holds for sev= eral seconds and then errors out. If there is no memory pressure, there is no pa= use 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= "=20 and it runs instantly with no other action. The other user, Bob Prohaske, provided information on his case and agreed t= o 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 lo= gs 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 runni= ng HEAD. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-241048-227>