From owner-freebsd-arm@freebsd.org Fri Jan 22 01:15:37 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 5109E4E6C80 for ; Fri, 22 Jan 2021 01:15:37 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DMLsz4pQkz3kJN for ; Fri, 22 Jan 2021 01:15:35 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 10M1FaZL066866 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 21 Jan 2021 17:15:36 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 10M1FZVD066865; Thu, 21 Jan 2021 17:15:35 -0800 (PST) (envelope-from fbsd) Date: Thu, 21 Jan 2021 17:15:35 -0800 From: bob prohaska To: Mark Millard Cc: freebsd-arm@freebsd.org, bob prohaska Subject: Re: Silent hang in buildworld, was Re: Invoking -v for clang during buildworld Message-ID: <20210122011535.GA66611@www.zefox.net> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8D0C2A4C-B616-47B9-864E-D846A6EBA3D6@yahoo.com> X-Rspamd-Queue-Id: 4DMLsz4pQkz3kJN X-Spamd-Bar: - X-Spamd-Result: default: False [-1.07 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; WWW_DOT_DOMAIN(0.50)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[zefox.net]; RBL_DBL_DONT_QUERY_IPS(0.00)[50.1.20.27:from]; AUTH_NA(1.00)[]; SPAMHAUS_ZRD(0.00)[50.1.20.27:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.97)[-0.970]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_SPF_NA(0.00)[no SPF record]; FREEMAIL_TO(0.00)[yahoo.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arm]; MID_RHS_WWW(0.50)[] 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 01:15:37 -0000 On Wed, Jan 20, 2021 at 08:46:28PM -0800, Mark Millard wrote: > > 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: > > World built in 1468 seconds, ncpu: 4, make -j4 > Kernel(s) GENERIC-NODBG built in 116 seconds, ncpu: 4, make -j4 > > So, somewhat under 30 minutes total. > > (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.) > > 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. > > 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). > > 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 > > 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. > > There are enough differences to not make the variations > in figures from our runs all that surprising. > > 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 <=1800 MiByte to > avoid what the documentation warns about for tradeoffs > for having too much swap space. > 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% 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.. 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 24 hours to complete, both world and kernel IIRC. It's a bit grim to see apparent performance decrease over 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. Thanks for reading, and a great deal of help... bob prohaska