From owner-freebsd-arm@freebsd.org Fri Jan 22 05:47:29 2021 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 6EB1E4EAE6C for ; Fri, 22 Jan 2021 05:47:29 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic312-25.consmr.mail.gq1.yahoo.com (sonic312-25.consmr.mail.gq1.yahoo.com [98.137.69.206]) (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 4DMSvh27B8z4R9r for ; Fri, 22 Jan 2021 05:47:28 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1611294446; bh=k0NZbzGEv6iqWU1LpAKrRs7h5mUVBrMQeyosjs0P2bs=; h=Subject:From:Date:To:From:Subject:Reply-To; b=ed6lrtmX29ajMsTfTdKLJnckCWfdFrhK6bJlxZ96j+DWaxZHgmYtzGqUafBSgAW+0/4SqCjKqyiDeh6f2u4759lUD6RWJ6CNndHKc9S29U8daAkHQd3Ww3pZeD7ptbQw7z/IJDYTOjZibtPisw0Q+j0EiIfn93RkU5bMQ4G+ntLn7cOnOdIznmb4my9zLPU7OWm5SE14byqUe7rp0M57bLNHjStb2/plcpK//ZZJJJFS0CHcDDkB6iNKPyUpUJ+RY0zusdU42M1OjTos8eqe6WBKMf+pwt9BGb2aD/6Qnj62wMcRMIRJHwILTj/2QOcujKGAvNiCLKtGsVBTbjnJvA== X-YMail-OSG: bcCIFqgVM1k5rQutXkxwWfdsVkOClPcMGF3aFiwJhm7rqUuxk_C.m.6ejhtTKz9 fK7g2xDj9V5x86y6RMPDVzE9iCQqt4aJHoI1Nn2tHUL5dKf8LGrtlNjOLmDP1OLFomTF23UDCrTX g1M8GuK.Oh5b6bo5ukfIRypoU56PtNOuO9RVB7RAWLgY2FhIif.mv3diJprinSi00ZFmhF3EXPJT Wfyk63AVUtrL39MEHdyAyGAMncSDmnlmRgzsYAW759LIME8FJ67VGmnP48_U3wis0Z3D91VKAqDd xwJjjHwRZ2USOS_WTtKoPX45tVsZDiH8E08Dkwy1z6ESyCDpiUbAfVOBR04esrJhYHkOL3HcCcH5 ch5lrZ1O8AphwpXOL1X1dnd9eeNez83CNL_WWPCoYeKg8495k7SBwImlAC_3_uEBXfzZpdB0IMFY oq.E.sE4rDcqZkGI2Es0pJ_84vgMmO5J6VC84c7HykjXWs.VQfgXohlxx5Nc6mi1Zl.1etIAApVn 5sInTiBBJOjXH96F3bfzRh.pmUttHqkOCHAkHh1N50ywWbJgfOXF1Z5OBvy3n_REUpzw_gohg3Pu AsLu9qZKAgH.GBqu89WCPvCdiYVXV2bBzL38Ft6e3IRimsBj4yytlOHYZrGi5eqqxUlZo5yywtK5 LH9tu1_AK.oVQhE8NvE1ZbGdU6hs7vkLvwNIwDre5SPKH8Es8IVTMw8eFFfdLjXEiLM30CAq_Snt sMwhgMqO_es1m3TuKMlebku2A3b.4B4icDO2i3A3vv2w0lYZ.jcA6jP3dixIeMTHiN1jVyo8BjDA M9skc.7x2QI22tpkui6GvAtgzMp9.ghL1Rbp2mFLusANsU5RfP7DGIv9w9JfIoe2EkV2ZQWaHOy9 cbJk4rF6YtnVXKQ3gPEe39xsOM1M723luty.Lpqt2dGeePSIlc0JukybdzAkNrXGlPvemBXxznIv tAiqWMJ6Me3ADEaDiRgftDHmYDPexKnZrsxjYrXCnhgTkTfKO4sPe6YSWqg6Cs.F3M2.Ja4KQnpa bYY0cITi5quqkYhqAQNDC2QWA6l1BuYy8rOVBaRPby3yitsKYrkafRF7PQoEngKLO.n07yuOmIy7 241bxDmr_aIzh_15QHFqG_dSHHy0MvbEx4XVf1UyEolkuyTb96xP3rQFocgno8gbfXKSJLYGRttA 9uPIllkANUSaT1daWGD4cq7Zt7DQwyweEhMAolD94pniNQm2Q0ZFCNaQV7M5R330UGSLSdbiJZxB TN9kzB1XvRhSwiCuDWxueHr1uGoRrWrIZaT1j1l_2ewdXi252nuLyOYD_ViP2ueYn8sC8jYB6rm7 .rVEAZBeY_1hDbG0HySAelIhznORqsd1p.6aF0TgBvMaEuorgzWO1UY3Eq7YBjn7zVqhIwYh3DOg eG2U1BgYZIkw1.v6LiK8NH8so0YdB9owPNij8a70hhia57dH9sNHFEXy9CzIBN9GPV3pCJE6PJtX vjQF7ckKFo9lVgf8gqARIDlsPePTwp7RR4bfwrnmxxpTjJfnXtMdH_lR30WiYGFtPCo2HXBoYQvw hduiDStDb8Bd.H.k2FLko1oH5lS0Do_2C17EnAGbJGBxseWBT5ZdahyZr.6D_rFRo.DBxkPc3jzt AJFQLkTNIs5jc2OXKhV8m_Oz7tSJ0evbSDms3q6M0U81MTjT9MPtx0LRapcfR4.9Uoyl8qy4ipT1 r3aZEcE.CtgW4sgfuu.i.971xBgDDx_VTdSlI3oxzeNlyPY1rzSUnsmg96B4no7ILgyx60QWkzKU 4zk2owvbYzcqnlmKJMegYF3wBSfZcwK3__uXl29m_WhGnpu38F7HNB5q3R_RCjMof6lB3r23ubxc fsYa_2MlWRrKqQhy7QwTCokxg7A_G.D2w8ZLK1wMcImmrntoElh6vyaTC6ALwqhk4xWy8axxkxzb bPWwZV3B7q1aX4sL._yTxjnIZXznt2hBEjmOFqt.eCv.kN01KmsylW7u064AlrKPTqi127mZTGPw .RqyOKgxGyqMmv8d9sHKDZvQ0tqKMHpqHwPIfHW4FGXY1v.Ol_Qlc6cwIH.BNrv5oa43jwQBtV3h ADPJwwcjx8TxsLN9jLh8o30QLi7cspRla0qR7lO2ZH0KuDMwJx.JJMv3wPy3dut0lzUnFQcoXO8g yfhTmcbxwUJvMQHKb.peI6MR7qowaOR65dkvJatdnAko.5tx9JS4L6n7gWApPW_9126SyTRl0rg1 fcWCmLsSTAxIhk4db6wOn.m6DEOadMVsMY4AfiFPzgQuYzVvxDo_HhStZQzty8nXcRQaz5lirY.Y e5oN8z9ASkbQakRHSCtWRwmclOwgLvpRMi_aRP_h9Ge.RBfZ5KQiWm6QIV3G4CD41N7YeaqMG1Dw GBtOnfcsrHHBjxmu.cQ65z06srYB_I7rd7qvtMCVygFTaZVW6j6kYZELfw26uqQweoxlAT5jdJqI jso0VD5kcbrPvcWv2pK9uMgvStJTl8c3EFfYqSARylSho6Y86efpGpUY- Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Fri, 22 Jan 2021 05:47:26 +0000 Received: by smtp423.mail.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID a925a8bba8b85f2e5664050205d674dc; Fri, 22 Jan 2021 05:47:25 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Subject: Re: Silent hang in buildworld, was Re: Invoking -v for clang during buildworld From: Mark Millard In-Reply-To: <655C6BAA-8B10-4130-A5C9-EDED6906207D@yahoo.com> Date: Thu, 21 Jan 2021 21:47:25 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <85889EAE-F579-4220-9185-944D9AA5075A@yahoo.com> <20210118015009.GA31353@www.zefox.net> <60CCCDE8-E3D3-4920-9FC0-A945330F6830@yahoo.com> <00104FAD-E32B-4DDE-80DD-FCEF14CEC06B@yahoo.com> <056845FE-7131-4951-96AF-805D07F7BE0D@yahoo.com> <20210121023358.GA58854@www.zefox.net> <8D0C2A4C-B616-47B9-864E-D846A6EBA3D6@yahoo.com> <20210122011535.GA66611@www.zefox.net> <655C6BAA-8B10-4130-A5C9-EDED6906207D@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3654.40.0.2.32) X-Rspamd-Queue-Id: 4DMSvh27B8z4R9r X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.50 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-0.999]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[98.137.69.206:from]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SPAMHAUS_ZRD(0.00)[98.137.69.206:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.206:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.206:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arm] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2021 05:47:29 -0000 On 2021-Jan-21, at 21:25, Mark Millard wrote: > On 2021-Jan-21, at 17:15, bob prohaska wrote: >=20 >> On Wed, Jan 20, 2021 at 08:46:28PM -0800, Mark Millard wrote: >>>=20 >>> You might want to have META_MODE do a build without >>> updating sources and leaving the existing build materials >>> in place. It would give you an idea of the lower bound on >>> how much time a minimal build would take in your context. >>> On the OPi+2E, for my context, for no linking-thread >>> constraint, an example was: >>>=20 >>> World built in 1468 seconds, ncpu: 4, make -j4 >>> Kernel(s) GENERIC-NODBG built in 116 seconds, ncpu: 4, make -j4 >>>=20 >>> So, somewhat under 30 minutes total. >>>=20 >>> (There can be some things that do get some rebuild activity >>> in such a build. Lots of things can end up relinked, so .full >>> and .debug and such regenerated.) >>>=20 >>> I'll note that for META_MODE to work well, you need to keep >>> using it so that its records stay up to date as a description >>> of the build materials that are to be the basis for the next >>> update. Forgetting to supply WITH_META_MODE would not be >>> good for approximately minimizing the rebuild work done. >>>=20 >>> I've never tried to compare how much more memory is used >>> under a debug kernel than a non-debug one. My use of >>> non-debug vs. your use of debug could explain a lot for >>> both memory use and some part of the time difference >>> compared to my reports. I've only used a debug kernel >>> to buildworld or buildkernel when trying to get evidence >>> for a system problem that was occurring during build* >>> operation(s). >>>=20 >>> QUOTE (from UPDATING) >>> NOTE TO PEOPLE WHO THINK THAT FreeBSD 13.x IS SLOW: >>> FreeBSD 13.x has many debugging features turned on, in both = the kernel >>> and userland. These features attempt to detect incorrect use = of >>> system primitives, and encourage loud failure through extra = sanity >>> checking and fail stop semantics. They also substantially = impact >>> system performance. If you want to do performance = measurement, >>> benchmarking, and optimization, you'll want to turn them off. = This >>> includes various WITNESS- related kernel options, INVARIANTS, = malloc >>> debugging flags in userland, and various verbose features in = the >>> kernel. Many developers choose to disable these features on = build >>> machines to maximize performance. (To completely disable = malloc >>> debugging, define WITH_MALLOC_PRODUCTION in /etc/src.conf and = rebuild >>> world, or to merely disable the most expensive debugging = functionality >>> at runtime, run "ln -s 'abort:false,junk:false' = /etc/malloc.conf".) >>> END QUOTE >>>=20 >>> I was using a 1008 MHz clocked OPi+2E. You may well have >>> been using a 600 MHz clocked RPi2B. I do not know if there >>> are L1 or L2 RAM caching differences involved. >>>=20 >>> There are enough differences to not make the variations >>> in figures from our runs all that surprising. >>>=20 >>> I see that you kept the 2048 MiByte total swap space, so >>> still exceeding the documented recommended-maximum for >>> the context. Since it used under 800 MiBytes, it would >>> seem that it would fit to use more like <=3D1800 MiByte to >>> avoid what the documentation warns about for tradeoffs >>> for having too much swap space. >>>=20 >>=20 >> For the time being I've reduced swap partition so the system >> reports >> Device 1K-blocks Used Avail Capacity >> /dev/da0s2b 786432 0 786432 0% >> /dev/sdda0s2b 786432 0 786432 0% >> Total 1572864 0 1572864 0% >>=20 >> That should somewhat reduce suspician that too much swap >> is the culprit when something unfamiliar goes wrong. For >> the sake of my own understanding it would be useful to >> provoke a failure attributable to excessive swap, just >> to see if it's specifically distinguishable..=20 >=20 > There may well be ports that just take too much > memory for an RPi2 v1.1, even for -j1. aarch64 > is more appropriate for when larger swap spaces > are required: they allow much more swap for the > same RAM size, even while staying in the tuning > range that applies to them by default. True even > of the RPi3 booted for aarch64 use. >=20 > There may be ports that take too much memory to > build on aarch64 with only 1 GiByte of RAM. Others > may sometimes build in configurations were failure > leaves questions of mistuning being involved. >=20 >> My puzzlement over the long compile time was motivated >> by memories of early experiments building world on a >> Pi2 v1.1 using the same hard disk. Those took around=20 >> 24 hours to complete, both world and kernel IIRC. It's >> a bit grim to see apparent performance decrease over=20 >> the years, if in fact memory serves accurately. Since >> I didn't keep the various test results it's impossible >> to verify whether I was using -current or -release. >=20 > You wrote about a RPi3 (not RPi2) -j4 build in 2018, > note its buildworld time frame: >=20 > QUOTE > A clean-start -j4 buildworld was run using four swap partitions. = Buildworld > finished in about 26 hours, so the added swap did not speed the = process=20 > compared to a single microSD-based swap setup. Total swap used peaked = at > 1321024k. > END QUOTE >=20 > Note that now the swap use is less than back then, FreeBSD > having avoided some -O2 related compile time/memory-use > issues in more recent times(?). >=20 > (I do not know the armv6/armv7/aarch64 booot type status.) >=20 > An RPi2 stable/11 buildworld quote (2017) is below, > note the total swap configured compared to modern > requirements (the text is from a crash report so the > time is not relevant): >=20 > QUOTE > last pid: 30305; load averages: 0.00, 0.38, 1.51 up 0+07:38:08 = 16:55:41 > 48 processes: 1 running, 45 sleeping, 2 waiting > CPU: 0.1% user, 0.0% nice, 0.1% system, 0.0% interrupt, 99.8% idle > Mem: 751M Active, 29M Inact, 135M Wired, 88M Buf, 8K Free > Swap: 256M Total, 64M Used, 192M Free, 25% Inuse > QUOTE >=20 > Apparently the clang4 related toolchain was before things > caused you to use large swap sizes --or you had not yet > tried large port builds yet. This was back in armv6 days. > (You reported that you used a file-based swap back then, > a possible cause of hangups.) I ran into list message content relative to the 256 MiByte swap configuration: QUOTE (2018-Feb-17) The best part is that a Pi2 running 11.0 managed to build world and = kernel=20 using 256 MB of md99 swap. It was using j2, but that's the only = difference.=20 IIRC it took about three days. END QUOTE So the 256M Total might not be not for -j4 but -j2 . > I did not find anything directly on point for your old > RPi2 experiments. >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)