Gentoo Archives: gentoo-dev

From: Sam James <sam@g.o>
To: gentoo-dev@l.g.o
Cc: Florian Schmaus <flow@g.o>
Subject: Re: [gentoo-dev] [PATCH] check-reqs.eclass: clamp MAKEOPTS for memory/RAM usage
Date: Wed, 05 Jan 2022 20:17:02
In Reply to: Re: [gentoo-dev] [PATCH] check-reqs.eclass: clamp MAKEOPTS for memory/RAM usage by Ulrich Mueller
1 > On 5 Jan 2022, at 19:53, Ulrich Mueller <ulm@g.o> wrote:
2 >
3 >>>>>> On Wed, 05 Jan 2022, Florian Schmaus wrote:
4 >
5 >>> That applies to all parallel builds though, not only to ebuilds
6 >>> inheriting check-reqs.eclass. By tweaking MAKEOPTS, we're basically
7 >>> telling the user that the --jobs setting in their make.conf is wrong,
8 >>> in the first place.
9 >
10 >> Yes, exactly. And it is a bandaid solution. But I believe that it will
11 >> do more good than evil. And it is probably only used until portage is
12 >> able to report to the user that the emerge failed due to OOM (which I
13 >> believe to be non-trivial to implement, but I am happy to be proven
14 >> otherwise).
15 >
16 > Obviously I disagree. Tweaking the value for a subset of packages isn't
17 > a solution to the problem.
18 >
19 > MAKEOPTS applies to all parallel builds, and users should set it to a
20 > value suitable for their system (i.e. number of CPUs, available memory,
21 > etc.). Maybe our documentation needs to be improved? I see that
22 > make.conf.example says "The suggested number for parallel makes is
23 > CPUs+1" which may not be the best possible advice.
24 >
26 As you've noted, the memory requirements vary per package,
27 and it was somewhat of an oversight/error to not include
28 the memory limit from the eclass variable instead here
29 (although I recall kind of deciding to go with this approach
30 for simplicity).
32 It's therefore nontrivial to come up with a good value for their
33 whole system :)
35 Our documentation has mostly been updated but apparently
36 make.conf.example hasn't been.


File name MIME type
signature.asc application/pgp-signature