Gentoo Archives: gentoo-dev

From: Florian Schmaus <flow@g.o>
To: Ulrich Mueller <ulm@g.o>
Cc: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] [PATCH] check-reqs.eclass: clamp MAKEOPTS for memory/RAM usage
Date: Wed, 05 Jan 2022 19:15:09
In Reply to: Re: [gentoo-dev] [PATCH] check-reqs.eclass: clamp MAKEOPTS for memory/RAM usage by Ulrich Mueller
1 On 05/01/2022 19.22, Ulrich Mueller wrote:
2 >>>>>> On Wed, 05 Jan 2022, Florian Schmaus wrote:
3 >
4 >> On 05/01/2022 09.28, Ulrich Mueller wrote:
5 >>>>>>>> On Tue, 04 Jan 2022, Sam James wrote:
6 >>>> Crank down MAKEOPTS jobs if MAKEOPTS="-jN" is too high for the
7 >>>> amount of RAM available (uses amount declared as needed
8 >>>> in the ebuild). Typically should be ~2GB per job.
9 >>> Where does this number 2 GB come from? The amount of RAM strongly
10 >>> depends on the programming language and other factors, so I don't
11 >>> believe that there's one number that can be used for everything.
12 >
13 >> Surely not, but 2 GiB seems like a good start. I guess it could become
14 >> an eclass variable that ebuilds could modify later (if the need
15 >> emerges).
16 >
17 > We already have an eclass variable, namely CHECKREQS_MEMORY. Do you want
18 > to introduce another one that is counting memory per job? I doubt that
19 > would be possible, because the amount of memory greatly varies within a
20 > single build. For example, it is different for compiler vs linker vs
21 > building the documentation.
23 I am not sure what the problem here supposed to be is.
26 >> It appears to me that the motivation for this change is to prevent
27 >> users from running into OOM situations when emerging a package. And I
28 >> believe that many users, especially novices, are not directly able to
29 >> determine that portage failed due to OOM, simply because there is no
30 >> direct hint in the build log. Hence opt-out appears to be sensible to
31 >> me here.
32 >
33 > That applies to all parallel builds though, not only to ebuilds
34 > inheriting check-reqs.eclass. By tweaking MAKEOPTS, we're basically
35 > telling the user that the --jobs setting in their make.conf is wrong,
36 > in the first place.
38 Yes, exactly. And it is a bandaid solution. But I believe that it will
39 do more good than evil. And it is probably only used until portage is
40 able to report to the user that the emerge failed due to OOM (which I
41 believe to be non-trivial to implement, but I am happy to be proven
42 otherwise).
44 - Flow