Date: Sat, 04 Apr 2020 02:49:28 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 241848] lib/googletest/gtest/tests: gmock-matchers_test.cc requires a pathological amount of memory to compile Message-ID: <bug-241848-227-JhFUoxYxa7@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-241848-227@https.bugs.freebsd.org/bugzilla/> References: <bug-241848-227@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D241848 --- Comment #19 from Mark Millard <marklmi26-fbsd@yahoo.com> --- (In reply to Mark Millard from comment #17) A 1 GiByte RAM armv7 test . . . I tested a RPi2 V1.2 based on armv7 head -r359427 as the context (self-hosted, from-scratch build), using -j2 with 1800 MiByte swap partition used for the 1 GiByte RPi2. vm.pageout_oom_seq=3D120 and vm.pfault_oom_attempts=3D-1 and USB SSD and the like again, avoiding the microsd card after the kernel loads. The 1800 MiByte swap avoided boot notices of the form: warning: total configured swap (... pages) exceeds maximum recommended amou= nt (... pages). I stayed somewhat under the recommended maximum. (stable/12 reportedly lists a smaller recommended maximum when its figure is exceeded, somewhat more than 1200 MiByte.) The build completed fine, with my odd top variant showing "maximum Observed" figures: Mem: 758544Ki MaxObsActive, 189972Ki MaxObsWired, 928060Ki MaxObs(Act+Wir) Swap: 527388Ki MaxObsUsed But it turned out that the high memory use time frame for gmock-matchers_test.cc was matched with a very low memory use activity. So the 527388Ki MaxObsUsed is on the low side for figuring out having margin to cover -j2 variability in what the paired activity might be. Other pairings could easily have used over 700 MiByte more (say, linking clang), and so have reached in the realm of 1400 to 1500 MiByte for swap, leaving, say, 400 MiBytes to 300 MiBytes unused. (I happened to be there to watch the top display over the period of time at issue, seeing the growth to 527388Ki MaxObsUsed.) I'd not push it to -j3 for armv7 FreeBSD with 1 GiByte RAM. Having swap fairly near (but under) the recommended maximum seems appropriate for -j2 . Appropriately configured, -j1 seems unlikely to be a problem for for 1 GiByte RAM stable/12 (swap space contributing, vm.pfault_oom_attempts=3D-1 contributing, vm.pageout_oom_seq=3D120 contributing). I've not experimented with the more problematical microsd cards instead of using the particular USB SSD's that I have around. In the microsd card context vm.pfault_oom_attempts=3D-1 is likely appropriate to avoid paging activity latency from leading to OOM kills. For reference: the build took somewhat less than 38 hrs. I will note that stable/12 does support vm.pfault_oom_attempts=3D-1 as of -r351776 (2019-Sep-3) and vm.pageout_oom_seq=3D120 for much longer. --=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-241848-227-JhFUoxYxa7>