Changes in / [3eb188e:d2eb97b]
- Files:
-
- 3 edited
Legend:
- Unmodified
- Added
- Removed
-
chapter04/aboutsbus.xml
r3eb188e rd2eb97b 27 27 28 28 <para>For example, consider a package whose compilation time is 4.5 29 SBUs. This means that if your system took 10minutes to compile and29 SBUs. This means that if your system took 4 minutes to compile and 30 30 install the first pass of binutils, it will take 31 <emphasis>approximately</emphasis> 45minutes to build the example package.31 <emphasis>approximately</emphasis> 18 minutes to build the example package. 32 32 Fortunately, most build times are shorter than one SBU.</para> 33 33 … … 37 37 numbers can vary by as much as dozens of minutes in some cases.</para> 38 38 39 <para>Before measuring the build time of any package (no matter Binutils 40 pass 1 or a package of which the SBU is being measured), make sure a 41 system power profile suitable to make the system running with the 42 maximum performance (and the maximum power consumption) is selected. Or 43 the measured SBU value may be severly inaccurate because the system may be 44 operated differently building Binutils pass 1 and the other package. 39 <para>On some newer systems, the motherboard is capable of contolling 40 the system clock speed. This can be controlled with a command such as 41 <command>powerprofilesctl</command>. This is not available in LFS, but 42 may be available on the host distro. After LFS is complete, it can be 43 added to a system with the procedures at the 44 <ulink url='&blfs-book;sysutils/power-profiles-daemon.html'> 45 BLFS power-profiles-daemon</ulink> page. 46 47 Before measuring the build time of any package it is advisable to use a 48 system power profile set for maximum performance (and maximum power 49 consumption). 50 51 Otherwise the measured SBU value may be inaccurate because the 52 system may react differently when building <xref linkend='ch-tools-binutils-pass1'/> 53 or other packages. 54 45 55 Be aware that a significant inaccuracy can still show up even if the same 46 profile (except one maximizing the performance) is used for both packages:47 the system may respond slower for <quote>saving the power</quote> building48 Binutils pass 1, because the system load seems only about 25% of the load49 building the other package (with <parameter>-j4</parameter>).</para>56 profile is used for both packages because the system may respond slower if 57 the system is idle when starting the build procedure. Setting the power 58 profile to <quote>performance</quote> will minimize this problem. And 59 obviously doing so will also make the system build LFS faster.</para> 50 60 51 <para>On most distros the power profile can be managed with either 52 <command>power-profiles-daemon</command> or <command>tuned</command>. 53 If the distro runs <command>power-profiles-daemon</command>, issue the 61 <para>If <command>powerprofilesctl</command> is available, issue the 54 62 <command>powerprofilesctl set performance</command> command to select 55 the <literal>performance</literal> profile. If the distro runs 56 <command>tuned</command>, issue the <command>tuned-adm profile 57 throughput-performance</command> command to select the 58 <literal>throughput-performance</literal> profile.</para> 59 60 <para>Even if you are not measuring the SBU values, it's still better to 61 select the power profile for maximum performance before building LFS, as 62 doing so can (obviously) make the system faster to build LFS 63 packages.</para> 63 the <literal>performance</literal> profile. Some distros provides the 64 <command>tuned-adm</command> command for managing the profiles instead of 65 <command>powerprofilesctl</command>, on these distros issue the 66 <command>tuned-adm profile throughput-performance</command> command to 67 select the <literal>throughput-performance</literal> profile.</para> 64 68 65 69 <note> … … 71 75 single processor build to properly analyze the error messages.</para> 72 76 73 <para>The times presented here are based upon using four cores (-j4). The 77 <para>The times presented here for all packages 78 (except <xref linkend='ch-tools-binutils-pass1'/> which is based on one core) 79 are based upon using four cores (-j4). The 74 80 times in Chapter 8 also include the time to run the regression tests for 75 81 the package unless specified otherwise.</para> -
chapter05/binutils-pass1.xml
r3eb188e rd2eb97b 6 6 ]> 7 7 8 <sect1 id="ch-tools-binutils-pass1" role="wrap" >8 <sect1 id="ch-tools-binutils-pass1" role="wrap" xreflabel="binutils-pass1"> 9 9 <?dbhtml filename="binutils-pass1.html"?> 10 10 -
chapter08/gcc.xml
r3eb188e rd2eb97b 162 162 </important> 163 163 164 <para>One set of tests in the GCC test suite is known to exhaust the default 165 stack, so increase the stack size prior to running the tests:</para> 166 167 <screen><userinput remap="test">ulimit -s 32768</userinput></screen> 164 <para>GCC may need more stack space compiling some extremely complex 165 code patterns. As a precaution for the host distros with a tight stack 166 limit, explicitly set the stack size hard limit to infinite. 167 On most host distros (and the final LFS system) the hard limit is 168 infinite by default, but there is no harm done by setting it explicitly. 169 It's not necessary to change the stack size soft limit because GCC will 170 automatically set it to an appropriate value, as long as the value does 171 not exceed the hard limit:</para> 172 173 <screen><userinput remap="test">ulimit -s -H unlimited</userinput></screen> 168 174 169 175 <para>Now remove/fix several known test failures:</para>
Note:
See TracChangeset
for help on using the changeset viewer.