Yocto Project Discussions
 help / color / mirror / Atom feed
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 22:35:11 +0200	[thread overview]
Message-ID: <5de817e9-0765-4759-a982-d4090d539828@gmail.com> (raw)
In-Reply-To: <4a525185-be6e-4993-be82-34e34054d823@gmail.com>

Hi

Op 28-07-2026 om 09:30 schreef Ferry Toth:
> 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.

Pushed my wrynose branch now: 
https://github.com/htot/meta-intel-edison/tree/wrynose

> 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
>>
> 
> 



  reply	other threads:[~2026-07-28 20:35 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
2026-07-28 20:35     ` Ferry Toth [this message]
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=5de817e9-0765-4759-a982-d4090d539828@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