https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241848
--- Comment #12 from Mark Millard <[email protected]> --- Just to add to the examples of what it takes to build and link gmock-matchers_test . . . In /usr/src/lib/googletest/gmock_main/tests/ I tried building gmock-matchers_test on an Orange Pi+ 2ed (armv7 Cortex-A7 with 2 GiBytes of RAM and 1740Mi swap/paging space). The context is head -r358132 . I use a modified version of top that keeps track of its sampled "Max. Observed Active" (MaxObsActive), MaxObsWired, MaxObs(Act+Wir), and, for swap use, MaxObsUsed (if any). It is also biased to present more digits (smaller unit size) and be explicit about powers of 2 factors being in use for memory size display. After finishing in somewhat over 20 minutes (under 25?), the odd variant of top was showing: 1019Mi MaxObsActive, 193444Ki MaxObsWired, 1146Mi MaxObs(Act+Wir) Swap: 1740Mi Total, 1740Mi Free That spans the link as well. So swap/paging space was not observed to be used --but clearly would have been on a 1 GiByte machine. Similarly Free RAM was never observed to be low but would have been on a 1 GiByte machine. An example aarch64 is a Rock64 (not Pro) with 4 GiBytes of RAM: 1753Mi MaxObsActive, 633084Ki MaxObsWired, 2368Mi MaxObs(Act+Wir) Swap: 4608Mi Total, 4608Mi Free (It shows a lot more Wired even without the build, just because of the larger amount of RAM.) So, even just looking at the MaxObsActive, it indicates that a 1 GiByte RAM machine would be paging/swaping and a 2 GiByte machine would likely do some as well (far less). There is a significant MaxObsActive difference between the armv7 and aarch64 contexts. But it would be interesting to see what a 2 GiByte aarch64 would be like. -- You are receiving this mail because: You are the assignee for the bug. _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "[email protected]"
