Re: [gentoo-dev] [PATCH] check-reqs.eclass: clamp MAKEOPTS for memory/RAM usage

[Ulrich Mueller]

>>>>> On Wed, 05 Jan 2022, Sam James wrote:

>> On 5 Jan 2022, at 08:28, Ulrich Mueller <ulm@g.o> wrote:
>>
>> 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.

Well, if the 2 GiB was a universal constant then it would be valid for
_all_ builds, not just the random subset inheriting check-reqs.eclass.

> 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).

Yeah, having the ebuild specify an estimate for the average memory usage
per job would be more correct.

These are all band-aids however. What we would really need are options
like GNU parallel's --memfree and --memsuspend.

> 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).

But it would defeat the YAFIYGI principle that we commonly apply. :)

Ulrich