From owner-freebsd-arm@freebsd.org Fri Jan 22 05:25:44 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 605C94EA6AA for ; Fri, 22 Jan 2021 05:25:44 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic315-8.consmr.mail.gq1.yahoo.com (sonic315-8.consmr.mail.gq1.yahoo.com [98.137.65.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 4DMSQZ3J6Hz3w4b for ; Fri, 22 Jan 2021 05:25:42 +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=1611293140; bh=Y9UbdF5nllyIozZ0H5mDB/2WsqBZjyeD62UlQs5G6HT=; h=Subject:From:Date:To:From:Subject:Reply-To; b=CaCTQAC71GHNojQ8Hk7hel2CJoaZfTV44IFATdBCNTcYbN0zpEXJ6qHAjrJxlXvnBys54x7SA1Y6XSwJQaEphI74YtqZPdoAkg7NzFSSVHBVaoSCIA2nlDBy5Pdc+zIge04BciaRaeHed3bzuct+eb1IhmEyvzmiBlzu4kj6kEMdChHoKS16BkZ/UT7v0N3FTBtgWqjLjM6/KoUjLAhDdSjk/Li+OBQMs2xRVsbG3jcnISnv/EBV1tF/3yuKGNg0zYQKt/RMy1DGW9mhjOxwz8Fi1BYmCjJvtA3+hT12eKftNcA/OCxWxGpIdWl5NbMOu6X6glwGdBklSliYSnBsag== X-YMail-OSG: uIJPxBkVM1m8a8TZoWwx4TGtFGI8CLnGvqNDTjo9wFrIzoWxexx3xm6zKIrsoGc _J7sMCMNL93yc3E3iq3tfm4WGNM_JlMxuoeMtEEL63bHXUDpiJGds30O1wGFUDRYhyurGKfZppw2 REDlVBXmLlDJGQFPXko.Sj7FCS0KxfE062ZUGfKbcnfKG_BTwgY3v0K4CCGADChhogN9w6BpgcMU QSKvzO612ol_tU0cCDlHhV0uyLCOwxpMQuR8ipXuAAjylePvVAO28UHvdMsFkSMOnYiOL24IyLyd MXBQMomZDypFB7DlnswrUJ7WJgrfMNu5sS7KaszWz2aETTiZqo5PSVpSQB4WU8bLDGVihvCVLqTi Rw.WpWEcR2.t7eRIMRtXoypd3Tyt.palM3Fw7NGC1wooihuLtD77gLNwBeqxzLqUri6TIfT_dzYP hYN2PEWtz_H3PS8li.EidcdV8e20r4LfsVksFlDtDugFJ6qCwg1GUqtPgJ2zPeP816mLbch3T_kS OMMG_na7BxAXGS8jYpEWwr2qRNsPIGZGyYohfgUDhOpKPvvhcwKh9xd7A9_784RQ2GTC2ntBSs2D AEK7FSywdL91fyMDVZWm2Pf..lNisgNYVT0PYjoK0FqKkc1QYMOpTFSFoVaxSojTmoyHBjznnEk1 FU5eBN.DtP1qsT.oYRuULKMdIOb4XyVT3p9qcOvfZRwNPQe3Q1qoxQxxEoaNE4At3mj.dEvu2yJA qUO0e5SX39X9kP8DfjmMlSd6M3bPJoi5hkoksh1KZMUf9Y3Mn.fhL06Be1XtM_C8Jw5I4ehKndS7 qfvdj4mTf._19mmTzUATpG6snMetqatPATYDePOCT3BHFJlknsqmyec3.gVMnIDji2UmUjO_tHVr ipZ4kUS0ze7WeHnlQzvSORv0mDYm.Sw0sIM1nSbvCRHldtObNXLMyCGNkHSK0ZcL.ezcrcSieUUz 9SNqHMpsL9Nrd_KWgUiEiobUZdRDE2A03ofQxTYHXARgLb2NEvuHol67c1yCzR4GhHEhhVkZkZU5 TmESKzqHmmiPuU9elOxPI6c_IeIiYSQaFKdxMpdJjfJEqWXFbcbmS9RCJXc3QmJ9bC1g4zAfoMDi pXcSpn_uvnNpsZwEA1BBKXhRkvCVlbOX8dHSgrPeCPa_VXPC6SZB6.GJ1fRChzKQ24q_N2.MRjtl ZiWA0KC7LDaHmrApaEVWspWM64tGaxfrDbDQSuu3otzd5gaEOwg.BbkJh3pHK6OHwaLbzzKfKJq4 UClv_otAng93UXZ8wDf0fmdCvUC7a5kTM6nMsxqXyBoW_QYwGqNyq7u1rzIILsXsNzurV1UIq4XO wcki117NHIQOL_f71akodBB8K92j0YbsQksV4If50Hu5ckwnGD5eBNJps0MQhTdMrgjiJseT7hnY ohhyPWLHLKpM6zf5jorLqaCX9z02RMMHsFhVuT6Lz6tjCxljpqymswTneayZ07AxIBZwd.pyro4V nzTTmfXZLA5gOUVDW2_rFEGsY2dZH0VtE.ZvUs.jC.IFIWHHMCLlQQMw3v3QBsWQtjvxsjmPWySq uLBGsRb1al3UcKgvyE2CMgBZmqO7ATNPdAfN0YZhaDzB9nJy.2WfWLVu_278QdIzeSkOixnBfL2e YqHzyfJBcuxyVNPcok9dRBzye6PyEu8K9koaWhUpRLsW8zUnNO91weh.JRee.8NLyQdxybEGYEiM j2OZ8CxetDpGD9AcjDeryL8ifSIWEDWTo0_qYOpZuIGFtLTIC6srjwVbuKUJUTrwSlH1lGPyoXjL UqrqTYPwZogffEgTQeoRfSNihd5kPW6qB0yWlr4KcVCQI75dU53HYHE8aHKvBopIuukXmNAf_a3b gl0KM5OxSYPRFBUCZozpVwTWvNRmAFAEUXVGask_CjyZxcEFib0iiXyWnFdScthhpu5JmzDbo7Nx QU.Z_G1UN0YmLMlywRPoDVutBMhQga1uZzsufbGxMdEFJN_MiiB18Ka4F.RW9oLLVRcPTnGXvtRD IwwpdCHB41xNxidRpCr81CYZU0GBx1TuROsm01o6jMFvAeZeSXyfDjFbVcsnwOSFurnYnfOK4is2 6V1OU_Uu4wU4BX.7CA1jRj5LXSiGf15dke9utkEPz0y1_rC5doBJa5scmgeK04k31Ch_Ebx2JIhr swPhO3H.kZmkP8Y.89Sh02CGsK4krCoe3GkNPjYanaUGycszcrV4SG.LJ8YyqCZsK1oLWHplSdqh GaFgb8ixuvB_2Rkhe1nELZF9YTJmWoPI5Aub1VRA8GZosLOGj6MG0sRYrr8Vo4xiB6S7Cwien.gA Lv.2lxGq8xTD.e30rPxCr5ewiLHCd9f9zidvkW63xVL8_vbn_TXfr25FjsFDLJsxjMWYs35cY1Cs QlWwerZGLM3ok3pJuTYTyAKiHlcKorHQJe_MhqVdnHVPB.gpNTpIX2p5J_lhiSM3Sh_y16vZRnVQ 9yiE0JFqbtJBp6m.IXK.kqsRq99_Y5fP5ZYlv06r0rN0o3SA_fnKwpR7q5DuBDJNghZsdDQLObmy JvwUyRKXANRf_fZX194J9oaKPX4gmUWKimN8UqjU- Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Fri, 22 Jan 2021 05:25:40 +0000 Received: by smtp407.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID fed2b8747f8d87e3fe2473acc1f799bc; Fri, 22 Jan 2021 05:25:36 +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: <20210122011535.GA66611@www.zefox.net> Date: Thu, 21 Jan 2021 21:25:34 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <655C6BAA-8B10-4130-A5C9-EDED6906207D@yahoo.com> 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> To: bob prohaska X-Mailer: Apple Mail (2.3654.40.0.2.32) X-Rspamd-Queue-Id: 4DMSQZ3J6Hz3w4b 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)[-1.000]; 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]; RBL_DBL_DONT_QUERY_IPS(0.00)[98.137.65.32:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; 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.65.32:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.32:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.32: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:25:44 -0000 On 2021-Jan-21, at 17:15, bob prohaska wrote: > 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 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. 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. > 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. You wrote about a RPi3 (not RPi2) -j4 build in 2018, note its buildworld time frame: 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 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(?). (I do not know the armv6/armv7/aarch64 booot type status.) 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): 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 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 did not find anything directly on point for your old RPi2 experiments. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)