Date: Thu, 21 Jan 2021 17:15:35 -0800 From: bob prohaska <fbsd@www.zefox.net> To: Mark Millard <marklmi@yahoo.com> Cc: freebsd-arm@freebsd.org, bob prohaska <fbsd@www.zefox.net> Subject: Re: Silent hang in buildworld, was Re: Invoking -v for clang during buildworld Message-ID: <20210122011535.GA66611@www.zefox.net> In-Reply-To: <8D0C2A4C-B616-47B9-864E-D846A6EBA3D6@yahoo.com> References: <85889EAE-F579-4220-9185-944D9AA5075A@yahoo.com> <20210118015009.GA31353@www.zefox.net> <60CCCDE8-E3D3-4920-9FC0-A945330F6830@yahoo.com> <A0427375-5515-4D3C-AF2A-915E60A836A7@yahoo.com> <00104FAD-E32B-4DDE-80DD-FCEF14CEC06B@yahoo.com> <D9878BB6-2693-4A04-9E1C-126E0D378F7B@yahoo.com> <056845FE-7131-4951-96AF-805D07F7BE0D@yahoo.com> <A6150F56-062F-4582-853A-319C1EE4DDCB@yahoo.com> <20210121023358.GA58854@www.zefox.net> <8D0C2A4C-B616-47B9-864E-D846A6EBA3D6@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20210122011535.GA66611>