Date: Wed, 20 Jan 2021 20:46:28 -0800 From: Mark Millard <marklmi@yahoo.com> To: bob prohaska <fbsd@www.zefox.net> Cc: Current FreeBSD <freebsd-current@freebsd.org>, freebsd-arm@freebsd.org Subject: Re: Silent hang in buildworld, was Re: Invoking -v for clang during buildworld Message-ID: <8D0C2A4C-B616-47B9-864E-D846A6EBA3D6@yahoo.com> In-Reply-To: <20210121023358.GA58854@www.zefox.net> References: <C75D3D9C-4284-4BE3-B2CD-5DC6BBB60843@yahoo.com> <20210117174006.GA30728@www.zefox.net> <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>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2021-Jan-20, at 18:33, bob prohaska <fbsd at www.zefox.net> wrote: >> . . . > A first OS build/install cycle on armv7 (RPI2) using meta mode=20 > finished without trouble. Sources were a day or two newer than=20 > the kernel, -j4 buildworld took 157121 seconds. Peak swap use=20 > was half again as much at 732932. No constraints on ld.lld=20 > beyond defaults. I'm a little surprised at the extreme slowness, > but this was a fully-debug'd-current kernel and sources were > slightly newer than existing world. >=20 > In case there's interest I've put what log files I could gather at > http://www.zefox.net/~fbsd/rpi2/buildworld/main-c950-gff1a307801/ The first META_MODE build has no META_MODE information from the prior build. 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 <=3D1800 MiByte to avoid what the documentation warns about for tradeoffs for having too much swap space. =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?8D0C2A4C-B616-47B9-864E-D846A6EBA3D6>