> On 5 Jan 2022, at 08:28, Ulrich Mueller <u...@gentoo.org> 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.) >
This is essentially "common law" (or "common lore" if you like!) and
is well-accepted as a good rule of thumb.
The number being larger doesn't really make any difference here;
the point is to help in cases where we're pretty sure there's going
to be a problem (only users of check-reqs.eclass, and we can
Introduce a variable to give ~RAM per job too if needed).
> Also not sure if I understand the arithmetic. Shouldn't it use
> CHECKREQS_MEMORY as the basis of the calculation?
As noted, I was sort of on the fence about whether to hardcode
or use the CHECKREQS_MEMORY value and I'll think about this
again. I went for the current approach partly to keep things simple
(to avoid needing min/max bits).
>
>> +# @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.
That would defeat the purpose. If it's opt-in, then people are already aware
of their settings being inappropriate, and should probably fix them.
This is also about reducing the number of support queries about
builds which failed for trivial reasons, as someone who has to handle
quite a lot of those (until such a time as we can implement better
detection, but this is also a generally nice UX improvement -- as
per what Florian/flow said).
signature.asc
Description: Message signed with OpenPGP
