Date: Mon, 23 Jul 2018 12:02:57 -0700 From: bob prohaska <fbsd@www.zefox.net> To: Mark Millard <marklmi@yahoo.com> Cc: Trev <freebsd-arm@sentry.org>, freebsd-arm@freebsd.org, bob prohaska <fbsd@www.zefox.net> Subject: Re: RPI3 swap experiments Message-ID: <20180723190257.GA47869@www.zefox.net> In-Reply-To: <4ED9B658-A5A8-4BA6-9412-EBB7150B4B66@yahoo.com> References: <20180630005145.GA43801@www.zefox.net> <6f3406e2-71f3-d0c2-2b65-703e1a1d3c25@sentry.org> <8e92b2b7-da61-3efb-7231-9fac76b2c1d4@sentry.org> <ba33d8a7-a849-3893-8016-0765ebe1c51f@sentry.org> <2deaaec3-f78f-0b09-5ca7-27e14c6979f9@sentry.org> <bc8da02c-4465-9634-6fd0-0af4c63aa49d@sentry.org> <20180723063526.GA45726@www.zefox.net> <AB5EE2E4-B2FD-4CA9-A993-04C2A4BE10AE@yahoo.com> <20180723155311.GB45726@www.zefox.net> <4ED9B658-A5A8-4BA6-9412-EBB7150B4B66@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jul 23, 2018 at 10:53:56AM -0700, Mark Millard wrote: > > My note was intended just as a caution, not as a claim of a specific bad > comparison. I did not know how you established the initial context for > the build. > Understood and appreciated! I posed the question about cleaning up because the docs I've seen imply that running make cleandir twice in /usr/src should remove things in /usr/obj on the second pass. At some point I looked and found residues below /usr/obj/usr (possibly just empty directories, I didn't check) so I added the rm -rf /usr/obj/usr.... as a precaution. I'm not entirely sure the precautions taken to insure a clean start are sufficient even now. > If you are getting the same (re)build activity each time, then things should be > similar and comparisons easier and more reliable for such contexts. > The only point of consistency is that failures now take the form of OOMA kills. When -j4 buildworld succeeds using the USB3.1 flash it's imperative (so far) that all swap be on microSD. When using the USB3.0 flash all the swap must be on that device. Mixing swap (some on USB, some on microSD) seems to fail reliably, always with OOMA kills, when either USB device is in use. Stress2 is no longer able to produce a prompt panic, even stalling the system takes most of a day. > On occasion builds that are updating the -r?????? might find CC=cc or LD=ld does > not match the source tree. Such builds would have a lot more activity and take > longer. (This seems the most likely large variation in activity given an explicit > cleanout before the build.) > > I have not been doing a detailed comparison of the activity in your various > builds. I've not been checking/comparing the overall build times either (for > builds that completed). > > A rule of thumb (for rebuilds that complete) on the same storage device > configuration: similar build times tend to be more directly comparable. Large > differences in build times suggest more cautious comparisons. It might also > suggest another rebuild (that would have, say, the matching source tree and > avoid the cross compiler build). Time tends to work as a rule of thumb only > for builds that complete unless similarity is confirmed for earlier stopping > points. > > Of course completing a build that includes rebuilding those cross tools is > more/better evidence suggesting a good build context. Multiple rounds of > doing so: even more. Here's a point I find confusing: What is the purpose of cross tools when the build is self-hosted? Is "cross-tools" a component of bootstrap tools? > > It is when a build that also built the cross tools, but that eventually > fails, that the comparisons are more complicated compared to successes > that did not build the cross tools(for example). > I've been using peak swap usage as a measure of test thoroughness: If swap usage hits 1.3-1.4 GB without errors I've thought the test successful. Thanks for reading, and all your counsel. bob prohaska
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180723190257.GA47869>