Re: Strange authorisation isuses:

On Thu, Jun 16, 2022 at 04:33:21PM +0200, Dragan wrote:
> 
> Besides that I have noticed strong deviations in SBU build time with SBU at
> max 21s with -j16 and 1min 15sec based on binutils standard and 73 sec as
> reported by jhalfs.
> 

Historically, we went for -j1 to report the initial SBU.  In those
days multicore machines were much less common.

On machines where I intend to edit something in BLFS, and often on
others (with my own hardening flags) just for interest, I rerun the
SBU on the freshly booted system (various things from BLFS, none of
which are likely to affect the SBU.  My repeat-SBU script, and my
initial build in LFS, are both -j1, everything else is usually -j4,
-j8 or -j12 (the latter for a 16 thread machine - gives me some cpu
availability for other things, particularly if I'm building LFS in
chroot, and prevents it swapping badly when building qtwebengine (I
accidentally specified only 32GB and some of that is used for the
video).

I don't see any issue with 1min 15sec and 73 sec, individual builds
can vary.

What I do notice is that the SBU recalculated in the freshly booted
system is usually significantly slower, e.g. on my latest build on a
zen2 I had 88.316s for the initial build, but 105.070s after
booting.  Then I threw that away because of problems with python
modules (trying to reinstall, I possibly deleted too much).  This
time I got 88.658s and 104.891s using the same host system and same
host kernel.

But on the (lesser) machine where I build without my own CFLAGS,
CXXFLAGS on a system for measuring, I tend to run my repeat-SBU
script several times (and occasionally there are weird outliers to
ignore - possibly relaed to cron jobs) and take an average.  The
same when I updated to gcc-12.1 in /opt (I was not ready to start a
new LFS with gcc-12, now nearly ready).

On that system, building itself was actually faster (132.666s ->
129.945s).  I then updated the kernel to include full retpoline
(previous used the AMD LFENCE which is now regarded as inadequate)
and that initially went out to 139.592s, but an average of three
builds came to 137.6053s.  People tell me the difference for them
with full retpoline was minimal.  For gcc-12.1 the individual readings were
much closer, but the average was now 143.8066s.

I'm guessing you are on intel (fast frequencies on "best" cores, and
perhaps vmware knows enough to use the best core in -j1).

Summary:

Only use -j1 for the SBU if you want to keep a check on things
(particularly, to compare the figure from a completed old build to
the figure from a completed new build.  On a VM I would be dubious
about doing that - jhalfs is not set to do that on a completed
system, and my gut feeling is that telling a VM to use N cores is
not exactly the ame as using N cores on a native machine.

If you do want to review the SBU on a completed system, expect some
variation on individual runs if there is *anything* else actve (that
includes SSDs which might decide to do some 'housekeeping') as well
as cron, ssh, other daemons.

ĸen
-- 
     "Happiness isn't happiness without a violin-playing goat."
                             -- Notting Hill

-- 
http://lists.linuxfromscratch.org/sympa/info/alfs-discuss
Unsubscribe: See the above information page