Date: Mon, 23 Jul 2018 10:53:56 -0700 From: Mark Millard <marklmi@yahoo.com> To: bob prohaska <fbsd@www.zefox.net> Cc: Trev <freebsd-arm@sentry.org>, freebsd-arm@freebsd.org Subject: Re: RPI3 swap experiments Message-ID: <4ED9B658-A5A8-4BA6-9412-EBB7150B4B66@yahoo.com> In-Reply-To: <20180723155311.GB45726@www.zefox.net> References: <20180629233937.GC35717@www.zefox.net> <0f137e06-214a-3e8c-a216-f061ec04ac2c@sentry.org> <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>
index | next in thread | previous in thread | raw e-mail
On 2018-Jul-23, at 8:53 AM, bob prohaska <fbsd at www.zefox.net> wrote: > On Mon, Jul 23, 2018 at 12:11:19AM -0700, Mark Millard wrote: >> >> >> On 2018-Jul-22, at 11:35 PM, bob prohaska <fbsd at www.zefox.net> wrote: >> >>>> . . . >>> There is some reason to think "newer" Sandisk Extreme devices differ, perhaps >>> in a bad way, from older devices. The older device in my tests is model >>> SDCZ80-064G and is simply labeled USB3.0. The newer, troublesome device >>> is model SDCZ800-064G and is labeled Extreme Go USB 3.1. There are reports >>> that the Extreme Go is slower, advising to buy the older devices if possible. >>> >>> The USB3.1 flash drive is back in test, with the results of a j4 buildworld >>> under r336567 at >>> http://www.zefox.net/~fbsd/rpi3/swaptests/r336567/ >>> >>> The worst case results are still fairly dismal, close to a minute. All the >>> swap was on microSD, so OOMA didn't strike and buildworld completed successfully. >>> Near as I can tell no errors were reported on the console. >> >> >> Rebuilds that do not rebuild the llvm materials (clang, lld, lldb, etc.) are not all that >> comparable to ones that do. (This is visible in the time differences in the builds that >> complete.) The llvm related build activity likely involves most of the potential >> swapping, for example. Also: lots of I/O. >> >> There can be two rebuilds of some of the llvm material. One stage with such is the >> cross-compiler: >> --- buildworld --- >> make[1]: "/usr/src/Makefile.inc1" line 341: SYSTEM_COMPILER: Determined that CC=cc matches the source tree. Not bootstrapping a cross-compiler. >> make[1]: "/usr/src/Makefile.inc1" line 346: SYSTEM_LINKER: Determined that LD=ld matches the source tree. Not bootstrapping a cross-linker. >> (it was not rebuilt in the example). The other involves the build of the system llvm materials for >> use in the (potentially) installed system, such as the system's clang. >> >> Taking an environment that worked for lack of llvm related rebuilds may not >> well indicate the result for rebuilds that would try to rebuild the llvm related >> materials. >> >> It is something to consider in what builds are compared, how they are >> compared, and what one infers from comparisons. >> > > The first step in the experiment is to run a cleanup script, consisting of > > make -j8 cleandir > cleandir.log && make -j8 cleandir > cleandir.log && rm -rf /usr/obj/usr/src && rm *.log > > Might this be insufficient to ensure a clean start? There's no obvious reason to build > a cross compiler, since this is an RPI3 building world for itself. Is there an error in the > cleanup script? 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. 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. 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. 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). === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4ED9B658-A5A8-4BA6-9412-EBB7150B4B66>