Changes in / [d2eb97b:3eb188e]

Files:

• chapter04/aboutsbus.xml (modified) (3 diffs)
• chapter05/binutils-pass1.xml (modified) (1 diff)
• chapter08/gcc.xml (modified) (1 diff)

chapter04/aboutsbus.xml

@@ -27 +27 @@
 
   <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
+  SBUs. This means that if your system took 10 minutes to compile and
   install the first pass of binutils, it will take
-  <emphasis>approximately</emphasis> 18 minutes to build the example package.
+  <emphasis>approximately</emphasis> 45 minutes to build the example package.
   Fortunately, most build times are shorter than one SBU.</para>
 
@@ -37 +37 @@
   numbers can vary by as much as dozens of minutes in some cases.</para>
 
-  <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.
+  <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.
+  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>
 
-  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). 
+  <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
+  <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>
 
-  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>
+  <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>
 
   <note>
@@ -75 +71 @@
     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
+    <para>The times presented here 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>

chapter05/binutils-pass1.xml

@@ -6 +6 @@
 ]>
 
-<sect1 id="ch-tools-binutils-pass1" role="wrap" xreflabel="binutils-pass1">
+<sect1 id="ch-tools-binutils-pass1" role="wrap">
   <?dbhtml filename="binutils-pass1.html"?>
 

chapter08/gcc.xml

@@ -162 +162 @@
     </important>
 
-    <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 -H unlimited</userinput></screen>
+   <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>
+
+<screen><userinput remap="test">ulimit -s 32768</userinput></screen>
 
     <para>Now remove/fix several known test failures:</para>