From owner-freebsd-arm@freebsd.org Mon Jul 23 17:54:07 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D2DD21051413 for ; Mon, 23 Jul 2018 17:54:06 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic316-8.consmr.mail.gq1.yahoo.com (sonic316-8.consmr.mail.gq1.yahoo.com [98.137.69.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5679287696 for ; Mon, 23 Jul 2018 17:54:06 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: de52GvIVM1nVafEBd1gND9lCOGyhpA9EdEFmEYRRnjQnI6c.AVVCXnehmuEuUgi 4eY9hKPd_Ow_7HgaV4Q0yY11M0h66F6W3iltST8D33Z3GhSXhS2E8eGMmP2J7u8eih_xccuim_T8 j6pWk3T1oEbvzqldfFR1IkJRDByXNGOS1Vg40F_xIu1aOCpy_IQ0wnJzlMYohRkC7UgHjX7VOCEK dHFjfwKCa2nuK1fbSPt_Ta8AYz2YgWWyane9MXi74qgG5I9S.T7x4GgRVus9b3.hZiFfFNjCxcNa hIPrwrpB6pkl98T1TXwk5HQP1K13Xf1Wm76yf7ILzoOb2rEVZVZATA_mKniVDcJEoBvNa2JKRf.d MCleUhRWINYs_05Eubyq42jRK3PaE_7zJjrW25XQEF8PLiI_Z1Zow0douBtDMMwrOf.sxlftgGtk Odk9Z8oRkrIqTASMOA0.Jb2gaN3cFQGgS1mXjGuQ.lXJSrTPWt8xCgVg083qhqeQavWEvOboPdSg 90_skTQEHxb2HwYa9.B6tBQ1jJ1V9TbespvUiO7IE3y5YNofAwAFAhQTFbBZUt.hIMVhFgLwgi.H jUKZ6swOIaY9LKH_F3bJKJz6CtM7S1syl6.3EzSLGrkdcJsJqmPZQSdyRsm2cn9XaYKhZt3lb_vB 4kaXA12KMuVvKpyYR0lO1JqERIsHT.3tnHnFpS2tYtrck3hpvf0ztgUzPQ0tp0_vOYEc9uU9jpxi J1IXgCiMBqlTj1mtw.n.qehHho9SS7Fk8KKEykoLDpX.Lgb7GtM1ZvMCZbgN.XeZOhGtqzdgPoVp 14HkQjwyuOwze7uVOjtllKFx6KaoqeSL4LOyChLpzdrAuPstaa7nVEhHiLQF0QXLVFoo7gUZ_fmR HJq6IXM5h7eHRIz3ZLLogbaE6CFIjiastOxvlntsZqFMdXd5m9_bTx8bX9fhh4zonFkiW6x2Y46o ucDOHK_R2laitqCO8Wf3pPCtqfm8njSjE0EywW0Rnd41uuLLCqgRkwgv4u8aA0Ereqf7MJrZHjsD 2DEQ4rxaH Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Mon, 23 Jul 2018 17:53:59 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp413.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 624a896f7e42f0b79fdd10575f371a4a; Mon, 23 Jul 2018 17:53:58 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: RPI3 swap experiments From: Mark Millard In-Reply-To: <20180723155311.GB45726@www.zefox.net> Date: Mon, 23 Jul 2018 10:53:56 -0700 Cc: Trev , freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <4ED9B658-A5A8-4BA6-9412-EBB7150B4B66@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> <2deaaec3-f78f-0b09-5ca7-27e14c6979f9@sentry.org> <20180723063526.GA45726@www.zefox.net> <20180723155311.GB45726@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2018 17:54:07 -0000 On 2018-Jul-23, at 8:53 AM, bob prohaska 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 = 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)