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

[Ulrich Mueller]

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

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

Ulrich