Re: Silent hang in buildworld, was Re: Invoking -v for clang during buildworld

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 
> finished without trouble.  Sources were a day or two newer than 
> the kernel, -j4 buildworld took 157121 seconds. Peak swap use 
> was half again as much at 732932. No constraints on ld.lld 
> 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.
> 
> 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 <=1800 MiByte to
avoid what the documentation warns about for tradeoffs
for having too much swap space.



===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)