aboutsummaryrefslogtreecommitdiffstats
path: root/meta-skeleton/recipes-core/busybox/busybox_%.bbappend
diff options
context:
space:
mode:
authorRoss Burton <ross@burtonini.com>2021-11-24 17:15:29 +0000
committerRichard Purdie <richard.purdie@linuxfoundation.org>2021-11-25 21:53:44 +0000
commit765d0f25ce48636b1838a5968e2dc15de2127428 (patch)
treea4c95735fbf22adf259b2aa6852aef5dd9d67432 /meta-skeleton/recipes-core/busybox/busybox_%.bbappend
parent57ea50fcfe81f47b93b9302d1aab2e81dcdd3105 (diff)
downloadopenembedded-core-contrib-765d0f25ce48636b1838a5968e2dc15de2127428.tar.gz
openembedded-core-contrib-765d0f25ce48636b1838a5968e2dc15de2127428.tar.bz2
openembedded-core-contrib-765d0f25ce48636b1838a5968e2dc15de2127428.zip
oe/utils: by default cap cpu_count() to 64 cores
Larger systems may have large numbers of cores, but beyond a certain point they can't all be used for compiling: whilst purely compute-intensive jobs can be parallelised to hundreds of cores, operations such as compressing (needs lots of RAM) or compiling (lots of I/O) don't scale linearly. For example, the Marvel ThunderX2 has 32 cores, each capable of executing four threads, and can be configured with two sockets, making 256 CPUs according to Linux. Zstd using 256 threads has been seen to fail to allocate memory during even small recipes such as iso-codes. Add a default cap of 64 CPUs to the cpu_count() method so that extreme parallisation is limited. 64 is high enough that meaningful gains beyond it are unlikely, but high enough that most systems won't be effected. Signed-off-by: Ross Burton <ross.burton@arm.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Diffstat (limited to 'meta-skeleton/recipes-core/busybox/busybox_%.bbappend')
0 files changed, 0 insertions, 0 deletions