From: michael.opdenacker@bootlin.com
To: docs@lists.yoctoproject.org
Cc: Michael Opdenacker <michael.opdenacker@bootlin.com>
Subject: [PATCH 1/2] ref-manual/variables.rst: expand BB_NUMBER_THREADS description
Date: Tue, 8 Nov 2022 21:40:16 +0100 [thread overview]
Message-ID: <20221108204017.494051-1-michael.opdenacker@bootlin.com> (raw)
From: Michael Opdenacker <michael.opdenacker@bootlin.com>
Explain that reducing its value to reduce system load
is not sufficient if PARALLEL_MAKE is not reduced as well.
Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
---
documentation/ref-manual/variables.rst | 27 ++++++++++++++++++++++++++
1 file changed, 27 insertions(+)
diff --git a/documentation/ref-manual/variables.rst b/documentation/ref-manual/variables.rst
index 9909622d7a..147679400f 100644
--- a/documentation/ref-manual/variables.rst
+++ b/documentation/ref-manual/variables.rst
@@ -530,6 +530,33 @@ system and gives an overview of their function and contents.
":ref:`dev-manual/common-tasks:speeding up a build`"
section in the Yocto Project Development Tasks Manual.
+ On the other hand, if your goal is to limit the amount of system
+ resources consumed by BitBake tasks, setting :term:`BB_NUMBER_THREADS`
+ to a number lower than the number of CPU threads in your machine
+ won't be sufficient. That's because each package will still be built
+ and installed through a number of parallel jobs specified by the
+ :term:`PARALLEL_MAKE` variable, which is by default the number of CPU
+ threads in your system, and is not impacted by the
+ :term:`BB_NUMBER_THREADS` value.
+
+ So, if you set :term:`BB_NUMBER_THREADS` to "1" but don't set
+ :term:`PARALLEL_MAKE`, most of your system resources will be consumed
+ anyway.
+
+ Therefore, if you intend to reduce the load of your build system by
+ setting :term:`BB_NUMBER_THREADS` to a relatively low value compared
+ to the number of CPU threads on your system, you should also set
+ :term:`PARALLEL_MAKE` to a similarly low value.
+
+ An alternative to using :term:`BB_NUMBER_THREADS` to keep the usage
+ of build system resources under control is to use the smarter
+ :term:`BB_PRESSURE_MAX_CPU`, :term:`BB_PRESSURE_MAX_IO` or
+ :term:`BB_PRESSURE_MAX_MEMORY` controls. They will prevent BitBake
+ from starting new tasks as long as thresholds are exceeded. Anyway,
+ as with :term:`BB_NUMBER_THREADS`, such controls won't prevent the
+ tasks already being run from using all CPU threads on the system
+ if :term:`PARALLEL_MAKE` is not set to a low value.
+
:term:`BB_SERVER_TIMEOUT`
Specifies the time (in seconds) after which to unload the BitBake
server due to inactivity. Set :term:`BB_SERVER_TIMEOUT` to determine how
--
2.34.1
next reply other threads:[~2022-11-08 20:40 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-08 20:40 michael.opdenacker [this message]
2022-11-08 20:40 ` [PATCH 2/2] ref-manual/variables.rst: expand PARALLEL_MAKE description michael.opdenacker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20221108204017.494051-1-michael.opdenacker@bootlin.com \
--to=michael.opdenacker@bootlin.com \
--cc=docs@lists.yoctoproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox