Re: [yocto] Limiting Yocto Memory Usage

[Ferry Toth <fntoth@gmail.com>]

Hi,

Op 28-07-2026 om 23:20 schreef Randy MacLeod:
> On 2026-07-28 16:35, Ferry Toth via lists.yoctoproject.org wrote:
>> 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
>
> Nice, are you interested in trying to get that or something based on 
> that work merged into oe-core/master ?
> I have been wanting to do for a while but other responsibilities keep 
> pushing it to the back burner or out of the kitchen completely !
>
Yeah that would be great. The patches were originally suggested by 
Richard Purdie. What spooks me a bit (based on earlier experience) is 
what additional stuff (self tests?) would be needed to get this accepted.
>
> ../Randy
>
>
>>
>>> 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.
>>>>>
>>>>>
>>>>>
>>>>
>>>> -- 
>>>> # Randy MacLeod
>>>> # Wind River Linux
>>>>
>>>
>>>
>>
>>
>> -=-=-=-=-=-=-=-=-=-=-=-
>> Links: You receive all messages sent to this group.
>> View/Reply Online (#66668):https://lists.yoctoproject.org/g/yocto/message/66668
>> Mute This Topic:https://lists.yoctoproject.org/mt/120272854/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