From: Ferry Toth <fntoth@gmail.com>
To: Randy MacLeod <randy.macleod@windriver.com>,
yocto@lists.yoctoproject.org, luis.merayo@ridgerun.com
Subject: Re: [yocto] Limiting Yocto Memory Usage
Date: Tue, 28 Jul 2026 09:30:48 +0200 [thread overview]
Message-ID: <4a525185-be6e-4993-be82-34e34054d823@gmail.com> (raw)
In-Reply-To: <2be84a80-e227-40cd-b63d-781dab0d9fb1@windriver.com>
Hi,
Op 14-07-2026 om 23:33 schreef Randy MacLeod:
> Hi Luis,
>
> On 2026-07-10 17:26, Luis Merayo via lists.yoctoproject.org wrote:
>> Hi,
>>
>> I would like to know if there is a way to limit Bitbake's Memory usage
>> to a specific percentage of the available RAM. For example, can the
>> Yocto build be limited to use a maximum of 70% of RAM?
> Not without using a container to do the build.
>>
>> Could these three variables achieve this?
>>
>> BB_PRESSURE_MAX_CPU <https://docs.yoctoproject.org/dev/ref-manual/
>> variables.html#term-BB_PRESSURE_MAX_CPU>, BB_PRESSURE_MAX_IO <https://
>> docs.yoctoproject.org/dev/ref-manual/variables.html#term-
>> BB_PRESSURE_MAX_IO> , BB_PRESSURE_MAX_MEMORY <https://
>> docs.yoctoproject.org/dev/ref-manual/variables.html#term-
>> BB_PRESSURE_MAX_MEMORY>
>>
>> I see the range for these variables is from 1 to 1000000, so I would
>> like to understand if there is a way to specify their values as a
>> function of the available RAM.
> No, there is only pressure when resources are over-commited so if you
> have free memory, there's no over-commit.
> https://docs.kernel.org/accounting/psi.html
>
> That's the design intent of the bitbake PRESSURE regulation system.
>
> There are plans to work on additional build system regulation.
>
> The first idea is to use the jobserver design:
> https://lore.kernel.org/openembedded-core/?q=GNU+AND+jobserver+
> +AND+f%3Amacleod
> and that would indirectly limit memory consumption since there would be
> fewer instances of gcc / rustc / ... running
> at once.
I do that, since 2 years or so.
https://github.com/htot/meta-intel-edison/commits/whinlatter/
In principle you need to catch the call to make and ninja (to force them
to use the jobserver) and patch bitbake (see setup.sh) to act as a
jobserver.
Now got it working on wrynose, still need to push that. Maybe later
today.With wrynose ninja has support for jobserver so doesn't need
patching, just a bbappend.
With this you can limit the number of compile jobs. On my builds I found
g++ compiles are the heaviest, about 1GB RAM each. So, with 16 cores I
need 16 GB.
Separately I found linking nodejs takes 5 x 5GB (5 jobs linking with
LTO?). So, I limited that to just one (since both nodejs and
nodejs-native can be built at the same time).
I'm not building rust so there may be other bottlenecks to resolve.
> There's also an even less clear idea about being able to restrict the
> build by specifying memory usage.
> That shouldn't be too hard to implement in bitbake in the same point
> where the pressure checks happen.
> Are you interested in working on that ?
>
> There are of course other levers to pull to reduce CPU/memory consumption:
> https://docs.yoctoproject.org/dev-manual/limiting-resources.html
>
> Have you tried them ?
>
>
>>
>> Regards,
>>
>> Luis
>>
>>
>>
>> File:RidgeRun.ai banner.png <https://ridgerun.ai/>
>> This email and any attachments are intended for the sole use of the
>> named recipient(s) and contain(s) confidential information that may be
>> proprietary, privileged, or copyrighted under applicable law. If you
>> are not the intended recipient, do not read, copy, or forward this
>> email message or any attachments, delete this email message and any
>> attachments immediately.
>>
>> -=-=-=-=-=-=-=-=-=-=-=-
>> Links: You receive all messages sent to this group.
>> View/Reply Online (#66637):https://lists.yoctoproject.org/g/yocto/message/66637
>> Mute This Topic:https://lists.yoctoproject.org/mt/120213825/3616765
>> Group Owner:yocto+owner@lists.yoctoproject.org
>> Unsubscribe:https://lists.yoctoproject.org/g/yocto/unsub [randy.macleod@windriver.com]
>> -=-=-=-=-=-=-=-=-=-=-=-
>>
>
> --
> # Randy MacLeod
> # Wind River Linux
>
next prev parent reply other threads:[~2026-07-28 7:30 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-10 21:26 Limiting Yocto Memory Usage Luis Merayo
2026-07-14 21:33 ` [yocto] " Randy MacLeod
2026-07-28 7:30 ` Ferry Toth [this message]
2026-07-28 20:35 ` Ferry Toth
2026-07-28 21:20 ` Randy MacLeod
2026-07-28 21:36 ` Ferry Toth
2026-07-29 21:30 ` Randy MacLeod
2026-07-16 8:22 ` Ulrich Ölmann
2026-07-21 15:22 ` Randy MacLeod
2026-07-22 6:23 ` Nate Kent
2026-07-22 8:00 ` Ulrich Ölmann
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=4a525185-be6e-4993-be82-34e34054d823@gmail.com \
--to=fntoth@gmail.com \
--cc=luis.merayo@ridgerun.com \
--cc=randy.macleod@windriver.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox