build: add load average limit to reduce CPU overcommitment

[dhewg]

For make and ninja based build systems, no new jobs are started if the load
average is greater than number_of_cores * 1.5.

Building an image on a 8-Core CPU, so using a load limit of 10.00 (earlier version of the patch which used * 1.25):

Before	After

(that's with building on tmpfs and autoremove)

[MilhouseVH]

[ -z "${CONCURRENCY_MAKE_LEVEL}" ] && export CONCURRENCY_MAKE_LEVEL=$(nproc)
[ -z "${CONCURRENCY_LOAD}" ] && export CONCURRENCY_LOAD=$(python3 -c "import os; print('%.2f' % (os.cpu_count() * 1.25))")

Is (or maybe, should?) CONCURRENCY_LOAD be linked to CONCURRENCY_MAKE_LEVEL?

For instance, if the user forces CONCURRENCY_MAKE_LEVEL to be 4 (on an 8 core CPU) should the defaultCONCURRENCY_LOAD then become 4 * 1.25, otherwise they'll still be over-commited by default (at 10)?

In which case we could use this:

[ -z "${CONCURRENCY_MAKE_LEVEL}" ] && export CONCURRENCY_MAKE_LEVEL=$(nproc)
[ -z "${CONCURRENCY_LOAD}" ] && export CONCURRENCY_LOAD=$(echo "scale=2; ${CONCURRENCY_MAKE_LEVEL} * 1.25" | bc)

Also, I'd like to allow a way to completely disable CONCURRENCY_LOAD, for example CONCURRENCY_LOAD=0 could mean we don't apply -l at all.

[MilhouseVH]

With this PR I think we can now lose this line, as it's redundant:

LibreELEC.tv/config/optimize

Line 4 in 254dedf

NINJA_OPTS=""

[MilhouseVH]

Could we also replace NINJA_OPTS with NINJA_FLAGS (exporting the latter, then removing from scripts/build, and mariadb and llvm packages), as this is functionally equivalent to MAKEFLAGS: ninja-build/ninja#1399

Alternatively I'd be happy for this to be addressed in a follow-up PR.

[dhewg]

• dropped the NINJA_OPTS line from config/optimize
• allow CONCURRENCY_LOAD=0 to disabled load limiting
• use number_of_cores * 1.5 per default, as build times regressed on some setups

[dhewg]

I didn't use NINJA_FLAGS since that isn't upstream and it looks like it won't get merged

[HiassofT]

I did a test on my laptop (i7-3740QM, 16GB RAM) and RPi4 build time with this PR was about the same as for plain master (01:26:54.453 vs 01:27:43.468 for master).

I recorded available memory (MemAvailable from /proc/meminfo) and load (1minute average, first value from /proc/loadavg) and it looks available memory is nothing we need to worry about much - at least with the 8 logical CPU cores I tested with (could be different for 32/64 core systems). Max memory usage was about 4GB in both cases, with the PR the memory usage peak near the end of the build wasn't observable though.

[MilhouseVH]

I didn't use NINJA_FLAGS since that isn't upstream and it looks like it won't get merged

Yeah, thanks for being on the ball - I looked at the ninja PR and thought to myself "this seems like a no-brainer" and that it had been merged. Little did I know the drama that was to follow, including an actual fork. Crazy. :(

[dhewg]

Updated screen, mame and mame2016 patches.
Because we need to patch that horrific genie we need to fix it's compilation and because of that the cross compilation.

[eli-schwartz]

Yeah, thanks for being on the ball - I looked at the ninja PR and thought to myself "this seems like a no-brainer" and that it had been merged. Little did I know the drama that was to follow, including an actual fork. Crazy. :(

The independent Ninja build language reimplementation in C, at https://github.com/michaelforney/samurai, supports this via the SAMUFLAGS environment variable.

[MilhouseVH]

@eli-schwartz

😄