mirror of
https://git.linuxfromscratch.org/lfs.git
synced 2025-01-18 04:57:38 +00:00
86 lines
4.1 KiB
XML
86 lines
4.1 KiB
XML
<?xml version="1.0" encoding="UTF-8"?>
|
|
<!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
|
|
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
|
|
<!ENTITY % general-entities SYSTEM "../general.ent">
|
|
%general-entities;
|
|
]>
|
|
|
|
<sect1 id="ch-preps-aboutsbus">
|
|
<?dbhtml filename="aboutsbus.html"?>
|
|
|
|
<title>About SBUs</title>
|
|
|
|
<para>Many people would like to know beforehand approximately how long
|
|
it takes to compile and install each package. Because Linux From
|
|
Scratch can be built on many different systems, it is impossible to
|
|
provide absolute time estimates. The biggest package (gcc) will
|
|
take approximately 5 minutes on the fastest systems, but could take
|
|
days on slower systems! Instead of providing actual times,
|
|
the Standard Build Unit (SBU) measure will be
|
|
used instead.</para>
|
|
|
|
<para>The SBU measure works as follows. The first package to be compiled is
|
|
binutils in <xref linkend="chapter-cross-tools"/>. The time it takes to
|
|
compile using one core is what we will refer to as the Standard
|
|
Build Unit or SBU. All other compile times will be expressed in terms of this
|
|
unit of time.</para>
|
|
|
|
<para>For example, consider a package whose compilation time is 4.5
|
|
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> 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
|
|
factors, including the host system's version of GCC. They are provided here
|
|
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>On some newer systems, the motherboard is capable of controlling
|
|
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 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>If <command>powerprofilesctl</command> is available, issue the
|
|
<command>powerprofilesctl set performance</command> command to select
|
|
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
|
|
book will vary even more than they normally would. In some cases, the make
|
|
step will simply fail. Analyzing the output of the build process will also
|
|
be more difficult because the lines from different processes will be
|
|
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 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>
|
|
|
|
</sect1>
|
|
|