diff --git a/documentation/ref-manual/usingpoky.xml b/documentation/ref-manual/usingpoky.xml
index 1a211ca78a..030448df0b 100644
--- a/documentation/ref-manual/usingpoky.xml
+++ b/documentation/ref-manual/usingpoky.xml
@@ -89,6 +89,145 @@
+
+ Speeding Up the Build
+
+
+ Build time can be an issue.
+ By default, the build system uses three simple controls to try and
+ maximize build efficiency:
+
+
+ BB_NUMBER_THREADS
+
+
+ BB_NUMBER_PARSE_THREADS
+
+
+ PARALLEL_MAKE
+
+
+ These three variables all scale to the number of processor cores
+ available on the build system.
+ This auto-scaling ensures that the build system fundamentally takes
+ advantage of potential parallel operations during the build
+ based on the build machine's capabilities.
+
+
+
+ If you need to achieve even faster builds than what the build system
+ produces by default, you can consider and implement some of the
+ following:
+
+
+ BB_NUMBER_THREADS,
+ BB_NUMBER_PARSE_THREADS, and
+ PARALLEL_MAKE:
+ As previously mentioned, the build system scales the values
+ for these variables.
+ However, you can manually override them in your
+ local.conf file if you are not satisfied
+ with the defaults.
+
+
+ File system type:
+ The file system type that the build is being performed on can
+ also influence performance.
+ Using ext4 is recommended as compared
+ to ext2 and ext3
+ due to ext4 improved features
+ such as extents.
+
+
+ Disabling the updating of access time using
+ noatime:
+ The noatime mount option prevents the
+ build system from updating file and directory access times.
+
+
+ Setting a longer commit:
+ Richard - I need some sort of general summary here about this.
+ I don't know the context.
+
+
+ The packaging backend:
+ Of the available packaging backends, IPK is the fastest.
+ Additionally, selecting a singular packaging backend also
+ helps.
+
+
+ Using /tmp as a temporary file system:
+ While this can help speed up the build, the benefits are
+ limited due to the compiler using
+ -pipe.
+ The build system goes to some lengths to avoid
+ sync() calls into the
+ file system on the principle that if there was a significant
+ failure, the
+ Build Directory
+ contents could easily be rebuilt.
+
+
+ Inheriting the
+ rm_work
+ class:
+ Inheriting this class has shown to speed up builds due to
+ significantly lower amounts of data stored in the data
+ cache as well as on disk.
+ Inheriting this class also makes cleanup of
+ TMPDIR
+ faster, at the expense of being easily able to dive into the
+ source code.
+ File system maintainers have recommended that the fastest way
+ to clean up large numbers of files is to reformat partitions
+ rather than delete files due to the linear nature of partitions.
+ This, of course, assumes you structure the disk partitions and
+ file systems in a way that this is practical.
+
+
+ Aside from the previous list, you should keep some trade offs in
+ mind that can help you speed up the build:
+
+
+ Exclude debug symbols and other debug information:
+ If you do not need these symbols and other debug information,
+ disabling the *-dbg package generation
+ can speed up the build.
+ You can disable this generation by setting the
+ INHIBIT_PACKAGE_DEBUG_SPLIT
+ variable to "1".
+
+
+ Disable static library generation for recipes derived from
+ autoconf or libtool:
+ Following is an example showing how to disable static
+ libraries and still provide an override to handle exceptions:
+
+ STATICLIBCONF = "--disable-static"
+ STATICLIBCONF_sqlite3-native = ""
+ EXTRA_OECONF += "${STATICLIBCONF}"
+
+ Notes
+
+
+ Some recipes need static libraries in order to work
+ correctly (e.g. pseudo-native
+ needs sqlite3-native).
+ Overrides, as in the previous example, account for
+ these kinds of exceptions.
+
+
+ Some packages have packaging code that assumes the
+ presence of the static libraries.
+ If so, you might need to exclude them as well.
+
+
+
+
+
+
+
+
Installing and Using the Result