Date: Thu, 21 Jan 2021 21:47:25 -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: <C502D267-5158-4658-BB02-EC67835015D3@yahoo.com> In-Reply-To: <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> <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> <655C6BAA-8B10-4130-A5C9-EDED6906207D@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2021-Jan-21, at 21:25, Mark Millard <marklmi at yahoo.com> wrote: > On 2021-Jan-21, at 17:15, bob prohaska <fbsd at www.zefox.net> 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)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?C502D267-5158-4658-BB02-EC67835015D3>