From: "Richard Purdie" <richard.purdie@linuxfoundation.org>
To: Ross Burton <ross@burtonini.com>,
OE-core <openembedded-core@lists.openembedded.org>
Subject: Re: [OE-core] Automatic cap on BB_NUMBER_THREADS and PARALLEL_MAKE
Date: Thu, 03 Dec 2020 23:05:00 +0000 [thread overview]
Message-ID: <9335029ffaa0db7dff5bb0b4acea4ff381bf4b54.camel@linuxfoundation.org> (raw)
In-Reply-To: <CAAnfSTuCTy4U60iJwtMm=N1PEaWjz6XyL_idgRXJVbzuLHggUw@mail.gmail.com>
On Thu, 2020-12-03 at 17:48 +0000, Ross Burton wrote:
> Hi,
>
> Currently, BB_NUMBER_THREADS and PARALLEL_MAKE use the number of
> cores
> available unless told otherwise. This was a good idea six years
> ago[1] but some modern machines are moving to very large core counts.
>
> For example, 88 core dual Xeons are fairly common. A ThunderX2 has
> 256
> cores (2 sockets, 4 hyperthreads per physical core). The Ampere Altra
> is dual socket 2*80=160 cores.
>
> At this level of parallelisation the sheer amount of I/O from the
> unpack storm is quite excessive. As a strawman argument, I propose a
> hard cap to the default BB_NUMBER_THREADS of -- and I'm literally
> making up numbers here -- 32. Maybe 64. Comments?
I've had no issues on 88 core systems. I'm not sure there is an
"automatic" value we can guess at here and it is mentioned in
local.conf for the user to customise...
What might make more sense is to have site.conf from a user's homedir
working better, although that does have issues of its own.
I do agree with Alex that having bitbake throttle on system load would
be nicer.
Cheers,
Richard
next prev parent reply other threads:[~2020-12-03 23:05 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-03 17:48 Automatic cap on BB_NUMBER_THREADS and PARALLEL_MAKE Ross Burton
2020-12-03 18:20 ` [OE-core] " Alexander Kanavin
2020-12-03 18:51 ` Konrad Weihmann
2020-12-04 6:39 ` Mikko Rapeli
2020-12-04 9:23 ` Jose Quaresma
2020-12-03 18:31 ` Andre McCurdy
2020-12-03 18:32 ` Paul Barker
2020-12-03 18:56 ` Khem Raj
2020-12-03 23:05 ` Richard Purdie [this message]
2020-12-04 6:38 ` Mikko Rapeli
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=9335029ffaa0db7dff5bb0b4acea4ff381bf4b54.camel@linuxfoundation.org \
--to=richard.purdie@linuxfoundation.org \
--cc=openembedded-core@lists.openembedded.org \
--cc=ross@burtonini.com \
/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