On Wed, 2022-01-05 at 09:28 +0100, Ulrich Mueller wrote: > > > > > > On Tue, 04 Jan 2022, Sam James wrote: > > > Crank down MAKEOPTS jobs if MAKEOPTS="-jN" is too high for the > > amount of RAM available (uses amount declared as needed > > in the ebuild). Typically should be ~2GB per job. > > Where does this number 2 GB come from? The amount of RAM strongly > depends on the programming language and other factors, so I don't > believe that there's one number that can be used for everything. > (If only considering C and C++ 2 GB seems to be excessive, i.e. it > will limit parallel build more than necessary. When linking, the > number > may be _much_ larger.)
https://wiki.gentoo.org/wiki/MAKEOPTS The rule of thumb is MAKEOPTS jobs should be the smaller number of: the size of RAM divided by 2GB or the number of threads the CPU has. You're free to propose a better scheme, but try compiling some template- heavy C++ code with 2GB/thread and -O3 and then WONTFIXing all the bug reports. OTOH, if you emake -j1, people complain about stuff being slower than glacial (https://bugs.gentoo.org/744088). Unless I see a better solution, sam's solution is the best way to avoid these annoying, rare, edge-case pitfalls. > Also not sure if I understand the arithmetic. Shouldn't it use > CHECKREQS_MEMORY as the basis of the calculation? > > > +# @ECLASS-VARIABLE: CHECKREQS_MEMORY_MANGLE_JOBS > > +# @USER_VARIABLE > > +# @DESCRIPTION: > > +# Allow packages to reduce the number of multiprocessing (e.g. > > make, ninja) jobs > > +# to lower memory usage. > > +: ${CHECKREQS_MEMORY_MANGLE_JOBS=yes} > > If anything, the feature should be opt-in rather than opt-out. > > Ulrich
