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>
next in thread | previous in thread | raw e-mail | index | archive | help
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: >>=20 >>=20 >> On 2018-Jul-22, at 11:35 PM, bob prohaska <fbsd at www.zefox.net> = wrote: >>=20 >>>> . . . >>> 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. >>>=20 >>> 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/ >>>=20 >>> 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. >>=20 >>=20 >> 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. >>=20 >> 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=3Dcc matches the source tree. Not bootstrapping a = cross-compiler. >> make[1]: "/usr/src/Makefile.inc1" line 346: SYSTEM_LINKER: Determined = that LD=3Dld 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. >>=20 >> 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. >>=20 >> It is something to consider in what builds are compared, how they are >> compared, and what one infers from comparisons. >>=20 >=20 > The first step in the experiment is to run a cleanup script, = consisting of >=20 > make -j8 cleandir > cleandir.log && make -j8 cleandir > cleandir.log = && rm -rf /usr/obj/usr/src && rm *.log >=20 > 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=20 > 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=3Dcc or = LD=3Dld 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). =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4ED9B658-A5A8-4BA6-9412-EBB7150B4B66>