All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Westermann, Oliver" <Oliver.Westermann@cognex.com>
To: Alexander Kanavin <alex.kanavin@gmail.com>
Cc: "yocto@lists.yoctoproject.org" <yocto@lists.yoctoproject.org>
Subject: RE: [EXTERNAL] Re: [yocto] nodejs do_compile eats all resources
Date: Tue, 27 Sep 2022 09:02:04 +0000	[thread overview]
Message-ID: <SA1PR06MB820996C847BB91D26CBBB4A186559@SA1PR06MB8209.namprd06.prod.outlook.com> (raw)
In-Reply-To: <CANNYZj8NzbdA8gWocxcX6TOJTPhFbCSEuNOFOVcHDB-vcD2muA@mail.gmail.com>

> Am Dienstag, 27. September 2022 10:50 schrieb Alexander Kanavin <alex.kanavin@gmail.com>:
>
> Do keep in mind that PARALLEL_MAKE can and should be set per recipe, so you can make-limit only the worst items.
> 
> Alex

Yeah, I'm currently using

PARALLEL_MAKE = "-j ${@int(oe.utils.cpu_count() / 4)}"

In a .bbappend to limit it, but keep it dynamic.

One question out of curiosity or lack of understanding:
Bitbake offers BB_NUMBER_THREADS to limit (IMHO) the number of bitbake tasks, eg parallel do_compile() tasks. Each of these however spawn the compiler with several parallel threads oe.utils.cpu_count (PARALLEL_MAKE defaults to cpu_count()). Why isn't it more common that we end up in issues due to cpu_count^2 threads being spawned? Shouldn't (roughly) BB_NUMBER_THREADS * PARALLEL_MAKE fully load the CPU?

Best regards, a curious Olli

  reply	other threads:[~2022-09-27  9:02 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-26 17:20 nodejs do_compile eats all resources Westermann, Oliver
2022-09-26 17:32 ` [yocto] " Alexander Kanavin
2022-09-27  8:34   ` [EXTERNAL] " Westermann, Oliver
2022-09-27  8:50     ` Alexander Kanavin
2022-09-27  9:02       ` Westermann, Oliver [this message]
2022-09-27  9:15         ` Martin Jansa
2022-09-26 22:11 ` Khem Raj

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=SA1PR06MB820996C847BB91D26CBBB4A186559@SA1PR06MB8209.namprd06.prod.outlook.com \
    --to=oliver.westermann@cognex.com \
    --cc=alex.kanavin@gmail.com \
    --cc=yocto@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.