gronod/lfs
1
0
Fork 0
mirror of https://git.linuxfromscratch.org/lfs.git synced 2025-06-18 19:29:21 +01:00
Code Issues Packages Projects Releases Wiki Activity

Automatic merge of trunk into multilib

Browse Source
This commit is contained in:
Thomas Trepl 2024-08-28 00:30:14 +02:00
commit d2eb97b78a
3 changed files with 41 additions and 29 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

56
chapter04/aboutsbus.xml
View File

@ -26,9 +26,9 @@
unit of time.</para>
<para>For example, consider a package whose compilation time is 4.5
SBUs. This means that if your system took 10 minutes to compile and
SBUs. This means that if your system took 4 minutes to compile and
install the first pass of binutils, it will take
<emphasis>approximately</emphasis> 45 minutes to build the example package.
<emphasis>approximately</emphasis> 18 minutes to build the example package.
Fortunately, most build times are shorter than one SBU.</para>
<para>SBUs are not entirely accurate because they depend on many
@ -36,31 +36,35 @@
to give an estimate of how long it might take to install a package, but the
numbers can vary by as much as dozens of minutes in some cases.</para>
<para>Before measuring the build time of any package (no matter Binutils
pass 1 or a package of which the SBU is being measured), make sure a
system power profile suitable to make the system running with the
maximum performance (and the maximum power consumption) is selected. Or
the measured SBU value may be severly inaccurate because the system may be
operated differently building Binutils pass 1 and the other package.
<para>On some newer systems, the motherboard is capable of contolling
the system clock speed. This can be controlled with a command such as
<command>powerprofilesctl</command>. This is not available in LFS, but
may be available on the host distro. After LFS is complete, it can be
added to a system with the procedures at the
<ulink url='&blfs-book;sysutils/power-profiles-daemon.html'>
BLFS power-profiles-daemon</ulink> page.
Before measuring the build time of any package it is advisable to use a
system power profile set for maximum performance (and maximum power
consumption).
Otherwise the measured SBU value may be inaccurate because the
system may react differently when building <xref linkend='ch-tools-binutils-pass1'/>
or other packages.
Be aware that a significant inaccuracy can still show up even if the same
profile (except one maximizing the performance) is used for both packages:
the system may respond slower for <quote>saving the power</quote> building
Binutils pass 1, because the system load seems only about 25% of the load
building the other package (with <parameter>-j4</parameter>).</para>
profile is used for both packages because the system may respond slower if
the system is idle when starting the build procedure. Setting the power
profile to <quote>performance</quote> will minimize this problem. And
obviously doing so will also make the system build LFS faster.</para>
<para>On most distros the power profile can be managed with either
<command>power-profiles-daemon</command> or <command>tuned</command>.
If the distro runs <command>power-profiles-daemon</command>, issue the
<para>If <command>powerprofilesctl</command> is available, issue the
<command>powerprofilesctl set performance</command> command to select
the <literal>performance</literal> profile. If the distro runs
<command>tuned</command>, issue the <command>tuned-adm profile
throughput-performance</command> command to select the
<literal>throughput-performance</literal> profile.</para>
<para>Even if you are not measuring the SBU values, it's still better to
select the power profile for maximum performance before building LFS, as
doing so can (obviously) make the system faster to build LFS
packages.</para>
the <literal>performance</literal> profile. Some distros provides the
<command>tuned-adm</command> command for managing the profiles instead of
<command>powerprofilesctl</command>, on these distros issue the
<command>tuned-adm profile throughput-performance</command> command to
select the <literal>throughput-performance</literal> profile.</para>
<note>
<para>When multiple processors are used in this way, the SBU units in the
@ -70,7 +74,9 @@
interleaved. If you run into a problem with a build step, revert to a
single processor build to properly analyze the error messages.</para>
<para>The times presented here are based upon using four cores (-j4). The
<para>The times presented here for all packages
(except <xref linkend='ch-tools-binutils-pass1'/> which is based on one core)
are based upon using four cores (-j4). The
times in Chapter 8 also include the time to run the regression tests for
the package unless specified otherwise.</para>
</note>

2
chapter05/binutils-pass1.xml
View File

@ -5,7 +5,7 @@
%general-entities;
]>
<sect1 id="ch-tools-binutils-pass1" role="wrap">
<sect1 id="ch-tools-binutils-pass1" role="wrap" xreflabel="binutils-pass1">
<?dbhtml filename="binutils-pass1.html"?>
<sect1info condition="script">

12
chapter08/gcc.xml
View File

@ -161,10 +161,16 @@ cd build</userinput></screen>
command below, where x is the number of CPU cores on your system.</para>
</important>
<para>One set of tests in the GCC test suite is known to exhaust the default
stack, so increase the stack size prior to running the tests:</para>
<para>GCC may need more stack space compiling some extremely complex
code patterns. As a precaution for the host distros with a tight stack
limit, explicitly set the stack size hard limit to infinite.
On most host distros (and the final LFS system) the hard limit is
infinite by default, but there is no harm done by setting it explicitly.
It's not necessary to change the stack size soft limit because GCC will
automatically set it to an appropriate value, as long as the value does
not exceed the hard limit:</para>
<screen><userinput remap="test">ulimit -s 32768</userinput></screen>
<screen><userinput remap="test">ulimit -s -H unlimited</userinput></screen>
<para>Now remove/fix several known test failures:</para>