My build machine has 8 cores + HT so bitbake enthusiastically assumes 16. However I have (only?) 16GB of RAM (+24GB swap space).

16GB of RAM has always been more then enough with 4 core + HT, but now building certain recipes (nodejs, but rust will probably do it as well) eats up more memory then there actually is RAM causing excessive swapping.

In fact the swapping is so excessive that just this single recipe determines largely the total image build time. However restricting bitbake (or actually parallel make) to use only 4 cores + HT sounds also like a waste.

I know this has been looked at in the past, but I think it needs fundamental resolving (other then, hé, why not add just another stick of memory).

What I do manually when I run into swapping so bad my desktop becomes unresponsive is ssh from another machine and then stop (not kill) the processes that use the most memory.

These then get swapped out, but not back in, allowing the remaining tasks to complete without swapping. Then when sufficient memory becomes free again I continue the stopped processes.

Isn't this something that could be added to bitbake to automate using memory efficiently?

Op 11-04-2021 om 17:27 schreef Alexander Kanavin:

This has been discussed several times in the past - the conclusion usually is that first this needs to be addresses upstream in make and ninja, e.g. that they support throttling new compiler instances when memory gets tight. Once that is available, bitbake can follow by throttling its own tasks as well.
Alex

Yes, and make project doesn't care, because make is called with -j 16 so that is what it does.

So here's my pitch: bitbake can stop processes spawned by make, because it knows that it started make on 4 recipies, each with -j 16. The individual makes don't know about each other.

And normally it's not an issue (compiling c), but sometimes compiling c++ it explodes (I saw 4GB ram in use for 1 g++ and there were 4 of them).

On Sun, 11 Apr 2021 at 17:23, Gmane Admin <gley-yocto@m.gmane-mx.org <mailto:gley-yocto@m.gmane-mx.org>> wrote:
My build machine has 8 cores + HT so bitbake enthusiastically assumes
16. However I have (only?) 16GB of RAM (+24GB swap space).
16GB of RAM has always been more then enough with 4 core + HT, but now
building certain recipes (nodejs, but rust will probably do it as well)
eats up more memory then there actually is RAM causing excessive
swapping.
In fact the swapping is so excessive that just this single recipe
determines largely the total image build time. However restricting
bitbake (or actually parallel make) to use only 4 cores + HT sounds
also
like a waste.
I know this has been looked at in the past, but I think it needs
fundamental resolving (other then, hé, why not add just another
stick of
memory).
What I do manually when I run into swapping so bad my desktop becomes
unresponsive is ssh from another machine and then stop (not kill) the
processes that use the most memory.
These then get swapped out, but not back in, allowing the remaining
tasks to complete without swapping. Then when sufficient memory becomes
free again I continue the stopped processes.
Isn't this something that could be added to bitbake to automate using
memory efficiently?

Op 11-04-2021 om 17:55 schreef Alexander Kanavin:

On Sun, 11 Apr 2021 at 17:49, Gmane Admin <gley-yocto@m.gmane-mx.org <mailto:gley-yocto@m.gmane-mx.org>> wrote:
Yes, and make project doesn't care, because make is called with -j
16 so
that is what it does.
So here's my pitch: bitbake can stop processes spawned by make, because
it knows that it started make on 4 recipies, each with -j 16. The
individual makes don't know about each other.
And neither they should. They can simply abstain from spawning new compilers if used RAM is, say, at 90% total. Then bitbake does not have to get involved in babysitting those makes.
Alex

Bitbake does a lot of babysitting anyway :-) And is pretty good at it too.

To me, fixing make et al. is more work and less effective then adding a feature to bitbake. The only way to know how much memory the compiler will use for each spawned compiler is to let it run. And then it's too late.

This memory issue is all over our eco system and nobody cares (kernel, make etc.) The only thing moving is systemd's oom killer will arrive and start killing processes. So that will just stop our builds from completing.

Yeah, I prefer a babysitter over a child murderer :-)

Ferry

Hi,

My comments are in-line.

On 11/04/2021 18:23, Gmane Admin wrote:

My build machine has 8 cores + HT so bitbake enthusiastically assumes 16. However I have (only?) 16GB of RAM (+24GB swap space).
16GB of RAM has always been more then enough with 4 core + HT, but now building certain recipes (nodejs, but rust will probably do it as well) eats up more memory then there actually is RAM causing excessive swapping.

The RAM usage depends heavily on what you are building ;) - It could be some crazy C++ stuff ;)

Is Linux your build host?

Then you can use cgroups to limit resources like memory.

Do you use a build container? It uses cgroups underneath.

e.g. docker:

https://docs.docker.com/config/containers/resource_constraints/

Regards,

Robert

Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands

T: +31 (0) 499 33 69 69
E: mike.looijmans@...
W: www.topic.nl

Please consider the environment before printing this e-mail
On 11-04-2021 17:23, Gmane Admin via lists.yoctoproject.org wrote:

My build machine has 8 cores + HT so bitbake enthusiastically assumes 16. However I have (only?) 16GB of RAM (+24GB swap space).

Been there, done that (8/16 cores with 8GB RAM).

The major cause is that bitbake will not just spawn 16 compiler threads, it will actually spawn up to 16 "do_compile" tasks which may spawn 16 compiler processes each, thus you'll be running a whopping 256 compilers. Bitbake may spawn a total of n^2 threads by default with "n" the detected number of cores.

The workaround I used was to limit the number of bitbake threads but leave the make threads at 16. Since most software these days is using parallel make, the impact on the build time of reducing the bb threads to 8 or 4 is negligible.

As for translating this into a bitbake feature, an implementation that comes to mind is to add a "weight" to each task. Most tasks would get a weight of just "1", but a (multithreaded) compile would be weighted "8" (some formula involving the number of CPUs) or so. This would stop bitbake spawning more processes early so that you don't get into the n^2 threads problem, and the number of processed that bitbake will spawn will be close to linear agin instead of quadratic as is is now.

Recipes that have excessive memory loads (usually C++ template meta-programming) can then just increase the weighting for the compile task.


--
Mike Looijmans

Hi,

Op 12-04-2021 om 04:25 schreef ChenQi:

I think you write a script to do all the WATCH-STOP-CONTINUE stuff.
e.g.
memwatch bitbake core-image-minimal
Options could be added.
e.g.
memwatch --interval 5 --logfile test.log bitbake core-image-minimal
This script first becomes a session leader, then forks to start the 'bitbake' command as its child process.
Then, every several seconds (say 10s by default), it checks the current memory usage, and according to its policy, determines whether to stop/continue some process or not.
For stopping the process, you can first get all its child process by simply using the 'ps' command.
e.g.
$ ps o vsize,comm,pid -s 28303 | sort -n -r
317284 emacs           12883
 28912 ps              36302
 26248 sort            36303
 21432 man             24797
 17992 bash            28303
  9852 pager           24807
   VSZ COMMAND           PID
Then skip the bitbake processes, stop the first one that uses the largest memory, record its PID.
For continuing processes, just start it according to the records. Maybe using FILO by default?
Best Regards,
Chen Qi

Yeah, so we would be having memwatch as a baby sitter.

I would be nicer to have it built into bitbake, but this would work too.

On 04/11/2021 11:23 PM, Gmane Admin wrote:

My build machine has 8 cores + HT so bitbake enthusiastically assumes 16. However I have (only?) 16GB of RAM (+24GB swap space).

16GB of RAM has always been more then enough with 4 core + HT, but now building certain recipes (nodejs, but rust will probably do it as well) eats up more memory then there actually is RAM causing excessive swapping.

In fact the swapping is so excessive that just this single recipe determines largely the total image build time. However restricting bitbake (or actually parallel make) to use only 4 cores + HT sounds also like a waste.

I know this has been looked at in the past, but I think it needs fundamental resolving (other then, hé, why not add just another stick of memory).

What I do manually when I run into swapping so bad my desktop becomes unresponsive is ssh from another machine and then stop (not kill) the processes that use the most memory.

These then get swapped out, but not back in, allowing the remaining tasks to complete without swapping. Then when sufficient memory becomes free again I continue the stopped processes.

Isn't this something that could be added to bitbake to automate using memory efficiently?

Op 12-04-2021 om 10:13 schreef Robert Berger@...:

Hi,
My comments are in-line.
On 11/04/2021 18:23, Gmane Admin wrote:

My build machine has 8 cores + HT so bitbake enthusiastically assumes 16. However I have (only?) 16GB of RAM (+24GB swap space).

16GB of RAM has always been more then enough with 4 core + HT, but now building certain recipes (nodejs, but rust will probably do it as well) eats up more memory then there actually is RAM causing excessive swapping.

The RAM usage depends heavily on what you are building ;) - It could be some crazy C++ stuff ;)

Yeah, C++. But apearently it's during the LTO phase where it eat my memory.

Is Linux your build host?

Yup.

Then you can use cgroups to limit resources like memory.

So then it would just fail the build?

Do you use a build container? It uses cgroups underneath.

Nope.

e.g. docker:
https://docs.docker.com/config/containers/resource_constraints/
Regards,
Robert

On 2021-04-11 12:19 p.m., Alexander Kanavin wrote:

make already has -l option for limiting new instances if load average is too high, so it's only natural to add a RAM limiter too.
  -l [N], --load-average[=N], --max-load[=N]
                              Don't start multiple jobs unless load is below N.
In any case, patches welcome :)

During today's Yocto technical call (1),
we talked about approaches to limiting the system load and avoiding
swap and/or OOM events. Here's what (little!) i recall from the
discussion, 9 busy hours later.

In the short run, instead of independently maintaining changes to
configurations to limit parallelism or xz memory usage, etc, we
could develop an optional common include file where such limits
are shared across the community.

In the longer run, changes to how bitbake schedules work may be needed.

Richard says that there was a make/build server idea and maybe even a
patch from a while ago. It may be in one of his poky-contrib branches.
I took a few minutes to look but nothing popped up. A set of keywords to
search for might help me find it.

Someone mentioned that while ninja has not been open to accepting any
patches that would complicate and potentially slow down builds, there
is a fork of ninja calls 'samurai' that does seem to be open to some
improvements that we could benefit from.

It was also suggested that there were existing defects in the YP BZ (2)
but I didn't find any earlier and it's too late in my day to start
looking now! If no one replies with a relevant BZ ID, I'll create one.

I'm sure I missed some things that were mentioned but Trevor Woerner
sometimes takes notes so I'll check on them once / if they are sent out.

../Randy


1) https://www.yoctoproject.org/public-virtual-meetings/

2) https://bugzilla.yoctoproject.org/

Alex
On Sun, 11 Apr 2021 at 18:08, Gmane Admin <gley-yocto@m.gmane-mx.org <mailto:gley-yocto@m.gmane-mx.org>> wrote:
Op 11-04-2021 om 17:55 schreef Alexander Kanavin:
> On Sun, 11 Apr 2021 at 17:49, Gmane Admin
<gley-yocto@m.gmane-mx.org <mailto:gley-yocto@m.gmane-mx.org>
> <mailto:gley-yocto@m.gmane-mx.org
<mailto:gley-yocto@m.gmane-mx.org>>> wrote:
>
>     Yes, and make project doesn't care, because make is called
with -j
>     16 so
>     that is what it does.
>
>     So here's my pitch: bitbake can stop processes spawned by
make, because
>     it knows that it started make on 4 recipies, each with -j 16. The
>     individual makes don't know about each other.
>
>
> And neither they should. They can simply abstain from spawning new
> compilers if used RAM is, say, at 90% total. Then bitbake does
not have
> to get involved in babysitting those makes.
>
> Alex
Bitbake does a lot of babysitting anyway :-) And is pretty good at
it too.
To me, fixing make et al. is more work and less effective then adding a
feature to bitbake. The only way to know how much memory the compiler
will use for each spawned compiler is to let it run. And then it's
too late.
This memory issue is all over our eco system and nobody cares (kernel,
make etc.) The only thing moving is systemd's oom killer will arrive
and
start killing processes. So that will just stop our builds from
completing.
Yeah, I prefer a babysitter over a child murderer :-)
Ferry

--
# Randy MacLeod
# Wind River Linux

I use

BUILDHISTORY_COMMIT_forcevariable = "1"
PARALLEL_MAKE = "-j 11"
BB_NUMBER_THREADS = "11"
INHERIT += "rm_work"
XZ_DEFAULTS = "--threads=8"

On Tue, Apr 13, 2021 at 6:15 PM Randy MacLeod
<randy.macleod@...> wrote:

On 2021-04-11 12:19 p.m., Alexander Kanavin wrote:

make already has -l option for limiting new instances if load average is
too high, so it's only natural to add a RAM limiter too.

-l [N], --load-average[=N], --max-load[=N]
Don't start multiple jobs unless load is
below N.

In any case, patches welcome :)

During today's Yocto technical call (1),
we talked about approaches to limiting the system load and avoiding
swap and/or OOM events. Here's what (little!) i recall from the
discussion, 9 busy hours later.

In the short run, instead of independently maintaining changes to
configurations to limit parallelism or xz memory usage, etc, we
could develop an optional common include file where such limits
are shared across the community.

In the longer run, changes to how bitbake schedules work may be needed.

Richard says that there was a make/build server idea and maybe even a
patch from a while ago. It may be in one of his poky-contrib branches.
I took a few minutes to look but nothing popped up. A set of keywords to
search for might help me find it.

Someone mentioned that while ninja has not been open to accepting any
patches that would complicate and potentially slow down builds, there
is a fork of ninja calls 'samurai' that does seem to be open to some
improvements that we could benefit from.

It was also suggested that there were existing defects in the YP BZ (2)
but I didn't find any earlier and it's too late in my day to start
looking now! If no one replies with a relevant BZ ID, I'll create one.

I'm sure I missed some things that were mentioned but Trevor Woerner
sometimes takes notes so I'll check on them once / if they are sent out.

../Randy


1) https://www.yoctoproject.org/public-virtual-meetings/

2) https://bugzilla.yoctoproject.org/

Alex

On Sun, 11 Apr 2021 at 18:08, Gmane Admin <gley-yocto@m.gmane-mx.org
<mailto:gley-yocto@m.gmane-mx.org>> wrote:

Op 11-04-2021 om 17:55 schreef Alexander Kanavin:
> On Sun, 11 Apr 2021 at 17:49, Gmane Admin
<gley-yocto@m.gmane-mx.org <mailto:gley-yocto@m.gmane-mx.org>
> <mailto:gley-yocto@m.gmane-mx.org
<mailto:gley-yocto@m.gmane-mx.org>>> wrote:
>
> Yes, and make project doesn't care, because make is called
with -j
> 16 so
> that is what it does.
>
> So here's my pitch: bitbake can stop processes spawned by
make, because
> it knows that it started make on 4 recipies, each with -j 16. The
> individual makes don't know about each other.
>
>
> And neither they should. They can simply abstain from spawning new
> compilers if used RAM is, say, at 90% total. Then bitbake does
not have
> to get involved in babysitting those makes.
>
> Alex
Bitbake does a lot of babysitting anyway :-) And is pretty good at
it too.

To me, fixing make et al. is more work and less effective then adding a
feature to bitbake. The only way to know how much memory the compiler
will use for each spawned compiler is to let it run. And then it's
too late.

This memory issue is all over our eco system and nobody cares (kernel,
make etc.) The only thing moving is systemd's oom killer will arrive
and
start killing processes. So that will just stop our builds from
completing.

Yeah, I prefer a babysitter over a child murderer :-)

Ferry

--
# Randy MacLeod
# Wind River Linux

On Tue, 2021-04-13 at 21:14 -0400, Randy MacLeod wrote:

On 2021-04-11 12:19 p.m., Alexander Kanavin wrote:

make already has -l option for limiting new instances if load average is
too high, so it's only natural to add a RAM limiter too.

   -l [N], --load-average[=N], --max-load[=N]
                               Don't start multiple jobs unless load is
below N.

In any case, patches welcome :)

During today's Yocto technical call (1),
we talked about approaches to limiting the system load and avoiding
swap and/or OOM events. Here's what (little!) i recall from the
discussion, 9 busy hours later.

In the short run, instead of independently maintaining changes to
configurations to limit parallelism or xz memory usage, etc, we
could develop an optional common include file where such limits
are shared across the community.

In the longer run, changes to how bitbake schedules work may be needed.

Richard says that there was a make/build server idea and maybe even a
patch from a while ago. It may be in one of his poky-contrib branches.
I took a few minutes to look but nothing popped up. A set of keywords to
search for might help me find it.

http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/wipqueue4&id=d66a327fb6189db5de8bc489859235dcba306237

Cheers,

Richard

Hi,
Op 14-04-2021 om 06:59 schreef Richard Purdie:

On Tue, 2021-04-13 at 21:14 -0400, Randy MacLeod wrote:

On 2021-04-11 12:19 p.m., Alexander Kanavin wrote:

make already has -l option for limiting new instances if load average is
too high, so it's only natural to add a RAM limiter too.

   -l [N], --load-average[=N], --max-load[=N]
                               Don't start multiple jobs unless load is
below N.

In any case, patches welcome :)

During today's Yocto technical call (1),
we talked about approaches to limiting the system load and avoiding
swap and/or OOM events. Here's what (little!) i recall from the
discussion, 9 busy hours later.

In the short run, instead of independently maintaining changes to
configurations to limit parallelism or xz memory usage, etc, we
could develop an optional common include file where such limits
are shared across the community.

I tried PARALLEL_MAKE_nodejs = "-j 1" from local.conf but that didn't work.

So I watched it run for a while. It compiles with g++ and as at about 0.5GB per thread, which is OK. In the end it does ld taking 4GB and it tries to do 4 in parallel. And then swapping becomes so heavy the desktop becomes unresponsive. Like I mentioned before ssh from another machine allows me to STOP one of them, allowing the remaining to complete. And then CONT the last one.

I worked around it now, by creating a bbappend for nodejs with only
PARALLEL_MAKE = "-j 2"

In the longer run, changes to how bitbake schedules work may be needed.

Richard says that there was a make/build server idea and maybe even a
patch from a while ago. It may be in one of his poky-contrib branches.
I took a few minutes to look but nothing popped up. A set of keywords to
search for might help me find it.

http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/wipqueue4&id=d66a327fb6189db5de8bc489859235dcba306237
Cheers,
Richard

On Sun, 2021-04-18 at 00:17 +0200, Gmane Admin wrote:

Hi,
Op 14-04-2021 om 06:59 schreef Richard Purdie:

On Tue, 2021-04-13 at 21:14 -0400, Randy MacLeod wrote:

On 2021-04-11 12:19 p.m., Alexander Kanavin wrote:

make already has -l option for limiting new instances if load average is
too high, so it's only natural to add a RAM limiter too.

    -l [N], --load-average[=N], --max-load[=N]
                                Don't start multiple jobs unless load is
below N.

In any case, patches welcome :)

During today's Yocto technical call (1),
we talked about approaches to limiting the system load and avoiding
swap and/or OOM events. Here's what (little!) i recall from the
discussion, 9 busy hours later.

In the short run, instead of independently maintaining changes to
configurations to limit parallelism or xz memory usage, etc, we
could develop an optional common include file where such limits
are shared across the community.

I tried PARALLEL_MAKE_nodejs = "-j 1" from local.conf but that didn't work.

It would need to be:

PARALLEL_MAKE_pn-nodejs = "-j 1"

So I watched it run for a while. It compiles with g++ and as at about
0.5GB per thread, which is OK. In the end it does ld taking 4GB and it
tries to do 4 in parallel. And then swapping becomes so heavy the
desktop becomes unresponsive. Like I mentioned before ssh from another
machine allows me to STOP one of them, allowing the remaining to
complete. And then CONT the last one.

I worked around it now, by creating a bbappend for nodejs with only
PARALLEL_MAKE = "-j 2"

If that works, the override above should also work. You do need the "pn-" 
prefix to the recipe name though.

Cheers,

Richard

Hi,
Op 18-04-2021 om 11:59 schreef Richard Purdie:

On Sun, 2021-04-18 at 00:17 +0200, Gmane Admin wrote:

Hi,
Op 14-04-2021 om 06:59 schreef Richard Purdie:

On Tue, 2021-04-13 at 21:14 -0400, Randy MacLeod wrote:

On 2021-04-11 12:19 p.m., Alexander Kanavin wrote:

make already has -l option for limiting new instances if load average is
too high, so it's only natural to add a RAM limiter too.

    -l [N], --load-average[=N], --max-load[=N]
                                Don't start multiple jobs unless load is
below N.

In any case, patches welcome :)

During today's Yocto technical call (1),
we talked about approaches to limiting the system load and avoiding
swap and/or OOM events. Here's what (little!) i recall from the
discussion, 9 busy hours later.

In the short run, instead of independently maintaining changes to
configurations to limit parallelism or xz memory usage, etc, we
could develop an optional common include file where such limits
are shared across the community.

I tried PARALLEL_MAKE_nodejs = "-j 1" from local.conf but that didn't work.

It would need to be:
PARALLEL_MAKE_pn-nodejs = "-j 1"

So I watched it run for a while. It compiles with g++ and as at about
0.5GB per thread, which is OK. In the end it does ld taking 4GB and it
tries to do 4 in parallel. And then swapping becomes so heavy the
desktop becomes unresponsive. Like I mentioned before ssh from another
machine allows me to STOP one of them, allowing the remaining to
complete. And then CONT the last one.

I worked around it now, by creating a bbappend for nodejs with only
PARALLEL_MAKE = "-j 2"

If that works, the override above should also work. You do need the "pn-"
prefix to the recipe name though.

And indeed it does, thanks so much for the tip.

Ferry

Cheers,
Richard

Op 14-04-2021 om 06:59 schreef Richard Purdie:

On Tue, 2021-04-13 at 21:14 -0400, Randy MacLeod wrote:

On 2021-04-11 12:19 p.m., Alexander Kanavin wrote:

make already has -l option for limiting new instances if load average is
too high, so it's only natural to add a RAM limiter too.

   -l [N], --load-average[=N], --max-load[=N]
                               Don't start multiple jobs unless load is
below N.

In any case, patches welcome :)

During today's Yocto technical call (1),
we talked about approaches to limiting the system load and avoiding
swap and/or OOM events. Here's what (little!) i recall from the
discussion, 9 busy hours later.

In the short run, instead of independently maintaining changes to
configurations to limit parallelism or xz memory usage, etc, we
could develop an optional common include file where such limits
are shared across the community.

In the longer run, changes to how bitbake schedules work may be needed.

Richard says that there was a make/build server idea and maybe even a
patch from a while ago. It may be in one of his poky-contrib branches.
I took a few minutes to look but nothing popped up. A set of keywords to
search for might help me find it.

http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/wipqueue4&id=d66a327fb6189db5de8bc489859235dcba306237
Cheers,
Richard

I like the idea. Unfortunately the patch doesn't apply to Gatesgarth, so I couldn't test it. Any chance you would be doing a refresh?

Op 05-06-2021 om 15:35 schreef Gmane Admin:

Op 14-04-2021 om 06:59 schreef Richard Purdie:

On Tue, 2021-04-13 at 21:14 -0400, Randy MacLeod wrote:

On 2021-04-11 12:19 p.m., Alexander Kanavin wrote:

make already has -l option for limiting new instances if load average is
too high, so it's only natural to add a RAM limiter too.

    -l [N], --load-average[=N], --max-load[=N]
                                Don't start multiple jobs unless load is
below N.

In any case, patches welcome :)

During today's Yocto technical call (1),
we talked about approaches to limiting the system load and avoiding
swap and/or OOM events. Here's what (little!) i recall from the
discussion, 9 busy hours later.

In the short run, instead of independently maintaining changes to
configurations to limit parallelism or xz memory usage, etc, we
could develop an optional common include file where such limits
are shared across the community.

In the longer run, changes to how bitbake schedules work may be needed.

Richard says that there was a make/build server idea and maybe even a
patch from a while ago. It may be in one of his poky-contrib branches.
I took a few minutes to look but nothing popped up. A set of keywords to
search for might help me find it.

http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/wipqueue4&id=d66a327fb6189db5de8bc489859235dcba306237

This patch resolves a starvation of a particular resource (execution cores), which is good.
However, the problem I am facing is starvation of another resource (memory).

Cheers,

Richard

I like the idea. Unfortunately the patch doesn't apply to Gatesgarth, so I couldn't test it. Any chance you would be doing a refresh?

Ok so I refreshed this patch my self and it seems to be working nicely (3000 out of 4000 tasks complete), except for one thing: do_configure for cmake-native fails and I don't see why. From the log:

loading initial cache file xxxxxx/out/linux64/build/tmp/work/x86_64-linux/cmake-native/3.18.2-r0/build/Bootstrap.cmk/InitialCacheFlags.cmake
-- The C compiler identification is GNU 10.3.0
-- The CXX compiler identification is GNU 10.3.0
-- Detecting C compiler ABI info
CMake Error: Generator: execution of make failed. Make command was: xxxxxx/out/linux64/poky/scripts/make-intercept/make cmTC_68352/fast &&
-- Detecting C compiler ABI info - failed
-- Check for working C compiler: xxxxxx/out/linux64/build/tmp/hosttools/gcc
CMake Error: Generator: execution of make failed. Make command was: xxxxxx/out/linux64/poky/scripts/make-intercept/make cmTC_f23a0/fast &&
-- Check for working C compiler: xxxxxx/out/linux64/build/tmp/hosttools/gcc - broken
CMake Error at Modules/CMakeTestCCompiler.cmake:66 (message):
The C compiler

"xxxxxx/out/linux64/build/tmp/hosttools/gcc"

is not able to compile a simple test program.

It fails with the following output:

Change Dir: xxxxxx/tmp/work/x86_64-linux/cmake-native/3.18.2-r0/build/CMakeFiles/CMakeTmp

Run Build Command(s):xxxxxx/out/linux64/poky/scripts/make-intercept/make cmTC_f23a0/fast && Permission denied
Generator: execution of make failed. Make command was: xxxxxx/out/linux64/poky/scripts/make-intercept/make cmTC_f23a0/fast &&

CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
CMakeLists.txt:7 (project)

Crazy. I don't see why making a complete recipe works fine, while making a test program during configure fails. Ideas?

[Please note: This e-mail is from an EXTERNAL e-mail address]

Op 14-04-2021 om 06:59 schreef Richard Purdie:

On Tue, 2021-04-13 at 21:14 -0400, Randy MacLeod wrote:

On 2021-04-11 12:19 p.m., Alexander Kanavin wrote:

make already has -l option for limiting new instances if load average is
too high, so it's only natural to add a RAM limiter too.

    -l [N], --load-average[=N], --max-load[=N]
                                Don't start multiple jobs unless load is
below N.

In any case, patches welcome :)

During today's Yocto technical call (1),
we talked about approaches to limiting the system load and avoiding
swap and/or OOM events. Here's what (little!) i recall from the
discussion, 9 busy hours later.

In the short run, instead of independently maintaining changes to
configurations to limit parallelism or xz memory usage, etc, we
could develop an optional common include file where such limits
are shared across the community.

In the longer run, changes to how bitbake schedules work may be needed.

Richard says that there was a make/build server idea and maybe even a
patch from a while ago. It may be in one of his poky-contrib branches.
I took a few minutes to look but nothing popped up. A set of keywords to
search for might help me find it.

http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/wipqueue4&id=d66a327fb6189db5de8bc489859235dcba306237

Cheers,

Richard

I like the idea. Unfortunately the patch doesn't apply to Gatesgarth, so
I couldn't test it. Any chance you would be doing a refresh?

I have reworked the patch and I'm doing some testing with it right now. Once I have collected some data (and possibly reworked it further, depending on results), perhaps I can have you test it out as well? That should be in the next day or two.

- Trevor