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

[Florian Schmaus]

On 05/01/2022 19.22, Ulrich Mueller wrote:
>>>>>> On Wed, 05 Jan 2022, Florian Schmaus wrote:
>
>> On 05/01/2022 09.28, 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.
>
>> Surely not, but 2 GiB seems like a good start. I guess it could become
>> an eclass variable that ebuilds could modify later (if the need
>> emerges).
>
> We already have an eclass variable, namely CHECKREQS_MEMORY. Do you want
> to introduce another one that is counting memory per job? I doubt that
> would be possible, because the amount of memory greatly varies within a
> single build. For example, it is different for compiler vs linker vs
> building the documentation.

I am not sure what the problem here supposed to be is.


>> It appears to me that the motivation for this change is to prevent
>> users from running into OOM situations when emerging a package. And I
>> believe that many users, especially novices, are not directly able to
>> determine that portage failed due to OOM, simply because there is no
>> direct hint in the build log. Hence opt-out appears to be sensible to
>> me here.
>
> That applies to all parallel builds though, not only to ebuilds
> inheriting check-reqs.eclass. By tweaking MAKEOPTS, we're basically
> telling the user that the --jobs setting in their make.conf is wrong,
> in the first place.

Yes, exactly. And it is a bandaid solution. But I believe that it will 
do more good than evil. And it is probably only used until portage is 
able to report to the user that the emerge failed due to OOM (which I 
believe to be non-trivial to implement, but I am happy to be proven 
otherwise).

- Flow