Can't limit linker concurrency

[Alexey Savchkov]

I build multiple C++ meson/ninja projects in parallel (on a build agent) and need to limit meson concurrency otherwise a project takes up all available system resources. Initially I tried to specify the -j option to 'meson compile' and it indeed limits the number of cc1plus processes but then comes the linker and throws a number of lto1-ltrans processes which is apparently not affected by the -j flag (it should perhaps?). Then in addition to -j I also set project('myproject', 'cpp', default_options: [..., 'backend_max_links=1', ...]) - again with no effect on lto1-ltrans. The only way I can contol the number of lto1-ltrans processes is by varying the number of CPUs in the system with lto1-ltrans's being exactly equal to the number of CPUs but this is only for localisation of the cause and isn't a real solution for me.

Is it by intension or a bug? Looks like it is impossible to build more than one project at one time.

I also can't use the -l limit based on the load average as the build which comes up first bumps the load to a high level leaving no room for the remaining projects.

My versions are:

CentOS Stream 9 (but reproducible also on Ubuntu 24.04)

$ meson --version    
0.63.3

$ ninja --version
1.10.2

These are the compildation flags that rpmbuild (%meson-macros) outputs:

+ CFLAGS='-O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SO
URCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/re
dhat-annobin-cc1  -m64 -march=x86-64-v2 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection'
+ export CFLAGS
+ CXXFLAGS='-O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_
SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/
redhat-annobin-cc1  -m64 -march=x86-64-v2 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection'
+ export CXXFLAGS
+ FFLAGS='-O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SO
URCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/re
dhat-annobin-cc1  -m64 -march=x86-64-v2 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -I/some/lib/path'
+ export FFLAGS
+ FCFLAGS='-O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_S
OURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/r
edhat-annobin-cc1  -m64 -march=x86-64-v2 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -I/some/lib/path'

Thanks a lot,
Alexey

[Jussi Pakkanen]

On Sun, 2 Feb 2025 at 10:09, 'Alexey Savchkov' via The Meson Build
System <meson...@googlegroups.com> wrote:

> I build multiple C++ meson/ninja projects in parallel (on a build agent) and need to limit meson concurrency otherwise a project takes up all available system resources. Initially I tried to specify the -j option to 'meson compile' and it indeed limits the number of cc1plus processes but then comes the linker and throws a number of lto1-ltrans processes which is apparently not affected by the -j flag (it should perhaps?). Then in addition to -j I also set project('myproject', 'cpp', default_options: [..., 'backend_max_links=1', ...]) - again with no effect on lto1-ltrans. The only way I can contol the number of lto1-ltrans processes is by varying the number of CPUs in the system with lto1-ltrans's being exactly equal to the number of CPUs but this is only for localisation of the cause and isn't a real solution for me.

What value does it report for `backend_max_links` if you do `meson
configure <builddir>`?

In general you should prefer setting those variables with command line
options to `meson setup` rather than writing them in build files.

[Lorenzo Cappelletti]

On Sunday, February 2, 2025 at 9:09:25 AM UTC+1 asa...@googlemail.com wrote:

$ meson --version    
0.63.3

 

That's very old! v1.7 came out last week. Even if it might not fix your problem. Can't you upgrade? Maybe with:

python -m venv venv

source venv/bin/activate

pip install --upgrade pip meson ninja

[Eli Schwartz]

On 2/2/25 3:09 AM, 'Alexey Savchkov' via The Meson Build System wrote:
> I build multiple C++ meson/ninja projects in parallel (on a build agent)
> and need to limit meson concurrency otherwise a project takes up all
> available system resources. Initially I tried to specify the -j option to
> 'meson compile' and it indeed limits the number of cc1plus processes but
> then comes the linker and throws a number of lto1-ltrans processes which is
> apparently not affected by the -j flag (it should perhaps?). Then in
> addition to -j I also set project('myproject', 'cpp', default_options:
> [..., 'backend_max_links=1', ...]) - again with no effect on lto1-ltrans.
> The only way I can contol the number of lto1-ltrans processes is by varying
> the number of CPUs in the system with lto1-ltrans's being exactly equal to
> the number of CPUs but this is only for localisation of the cause and isn't
> a real solution for me.
>
> Is it by intension or a bug? Looks like it is impossible to build more than
> one project at one time.

If you're seeing too many lto1-ltrans processes then this is not
controlled by backend_max_links or even -j1.

> These are the compildation flags that rpmbuild (%meson-macros) outputs:
>

> + CFLAGS='-O2 -flto=auto -ffat-lto-objects [......]


Using -j1 limits to a single GCC linker job at a time. GCC's linker
support then runs "auto" number of lto1-ltrans jobs, which can
communicate with the GNU Make jobserver to limit the parallelism but
otherwise uses as many processes as you have CPUs.

This is a Ninja bug that may be fixed by
https://github.com/ninja-build/ninja/pull/2506

The other option is to configure meson with

-D b_lto_threads=1

to prevent LTO from using more than one job at a time. This will prevent
sharing resources across multiple projects at all, but at least you
won't have problematic system resource exhaustion.


--
Eli Schwartz

[Alexey Savchkov]

Thank you all for your quck replies and useful suggestions.

Meanwhile I've found out more details about the presence and operation of lto1-ltrans but Eli's precise explanation made it completely clear.

Alexey

воскресенье, 2 февраля 2025 г. в 21:52:53 UTC+7, eschw...@gmail.com: