Re: [yocto] Limiting Yocto Memory Usage
Ferry Toth <[email protected]> Tue, 28 Jul 2026 22:35:11 +0200
| Newsgroups | org.yoctoproject.lists.yocto |
|---|---|
| Message-ID | <[email protected]> |
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:[email protected] >>> Unsubscribe:https://lists.yoctoproject.org/g/yocto/unsub >>> [[email protected]] >>> -=-=-=-=-=-=-=-=-=-=-=- >>> >> >> -- >> # Randy MacLeod >> # Wind River Linux >> > >