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

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






_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[email protected]"