Date: Thu, 21 Jan 2021 21:25:34 -0800 From: Mark Millard <marklmi@yahoo.com> To: bob prohaska <fbsd@www.zefox.net> Cc: freebsd-arm@freebsd.org Subject: Re: Silent hang in buildworld, was Re: Invoking -v for clang during buildworld Message-ID: <655C6BAA-8B10-4130-A5C9-EDED6906207D@yahoo.com> In-Reply-To: <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> <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> <20210122011535.GA66611@www.zefox.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2021-Jan-21, at 17:15, bob prohaska <fbsd at www.zefox.net> 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)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?655C6BAA-8B10-4130-A5C9-EDED6906207D>