Date: Mon, 23 Jul 2018 08:53:11 -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: <20180723155311.GB45726@www.zefox.net> In-Reply-To: <AB5EE2E4-B2FD-4CA9-A993-04C2A4BE10AE@yahoo.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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? Thanks for reading! bob prohaska
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180723155311.GB45726>