| Newsgroups |
gmane.linux.lfs.automated |
| Message-ID |
<[email protected]> |
On 16/06/2022 22:46, Bruce Dubbs ([email protected] via alfs-discuss
Mailing List) wrote:
> 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
Bruce,
Thanks for the scripts.
About timing: SBU of 75 sec was based on -j1 and not -j16. I have set
binutils to be built without optimisation.
On the same system in VM I got SBU between 20 aand 22 when building
using my own scripts and that is inclusief unpacking source code and
logging using -j16. But maintaining scripts between dev releases is just
to much time consuming and mistake prone.
On wsl using -j24 I got times between 18,9 and 19,5 sec using full scale
virtualization available using the same script. But with wsl enabled is
Virtual Box practically useless, it feels like "good old time" of 8080
and I have thrown it away.
What have realy surprised me is surprisingly low time of Kernel build 93
seconds. I have already booted in the system and it's looks ok. I will
take deeper look at the issue in chroot.
Total build time is not issue. Multitasking with some power to spare...
Dragan
--
http://lists.linuxfromscratch.org/sympa/info/alfs-discuss
Unsubscribe: See the above information page