Re: Strange authorisation isuses:

On 6/16/22 11:39, Ken Moffat ([email protected] via alfs-discuss Mailing List) 
wrote:
> 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.

Ken,  I agree with everything you say, but would like to point out that the SBU time 
for binutils-pass1 is with the host's version of gcc, but packages in Chapter 8 are 
done with the lfs version.

For instance, my SBU time at -j1 on my LFS11.1 system was about 95 seconds with 
gcc11, but with the host using gcc12, the time is now 101 seconds.

If I do not care about timing I build at -j22 on a 24 core system.  All of jhalfs 
without the kernel now takes about 26 SBU or roughly 45 minutes.

   -- Bruce

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