1 |
Am Mi., 5. Jan. 2022 um 19:22 Uhr schrieb Ulrich Mueller <ulm@g.o>: |
2 |
> |
3 |
> >>>>> On Wed, 05 Jan 2022, Florian Schmaus wrote: |
4 |
> |
5 |
> > On 05/01/2022 09.28, Ulrich Mueller wrote: |
6 |
> >>>>>>> On Tue, 04 Jan 2022, Sam James wrote: |
7 |
> >>> Crank down MAKEOPTS jobs if MAKEOPTS="-jN" is too high for the |
8 |
> >>> amount of RAM available (uses amount declared as needed |
9 |
> >>> in the ebuild). Typically should be ~2GB per job. |
10 |
> >> Where does this number 2 GB come from? The amount of RAM strongly |
11 |
> >> depends on the programming language and other factors, so I don't |
12 |
> >> believe that there's one number that can be used for everything. |
13 |
> |
14 |
> > Surely not, but 2 GiB seems like a good start. I guess it could become |
15 |
> > an eclass variable that ebuilds could modify later (if the need |
16 |
> > emerges). |
17 |
> |
18 |
> We already have an eclass variable, namely CHECKREQS_MEMORY. Do you want |
19 |
> to introduce another one that is counting memory per job? I doubt that |
20 |
> would be possible, because the amount of memory greatly varies within a |
21 |
> single build. For example, it is different for compiler vs linker vs |
22 |
> building the documentation. |
23 |
> |
24 |
> > It appears to me that the motivation for this change is to prevent |
25 |
> > users from running into OOM situations when emerging a package. And I |
26 |
> > believe that many users, especially novices, are not directly able to |
27 |
> > determine that portage failed due to OOM, simply because there is no |
28 |
> > direct hint in the build log. Hence opt-out appears to be sensible to |
29 |
> > me here. |
30 |
> |
31 |
> That applies to all parallel builds though, not only to ebuilds |
32 |
> inheriting check-reqs.eclass. By tweaking MAKEOPTS, we're basically |
33 |
> telling the user that the --jobs setting in their make.conf is wrong, |
34 |
> in the first place. |
35 |
|
36 |
Well, I'm using a safe combination of jobs and load-average, maybe the |
37 |
documentation should be tweaked instead. |
38 |
|
39 |
I'm using |
40 |
|
41 |
MAkEOPTS="--jobs=12 --load-average=8" |
42 |
|
43 |
on a 8x2+4 core CPU. I choose less then the available 20 cores because |
44 |
I'm also running multiple ebuilds in parallel to make better use of |
45 |
resources while most packages run their configure phase (which for |
46 |
small packages always takes longer than the build itself): |
47 |
|
48 |
EMERGE_DEFAULT_OPTS="--jobs=12 --load-average 10" |
49 |
|
50 |
The "--jobs" parameter is mostly a safe-guard against "make" or |
51 |
"emerge" overshooting the system resources which would happen if |
52 |
running unconstrained without "--load-average". The latter parameter |
53 |
OTOH tunes the parallel building processes automatically to the |
54 |
available resources. If the system starves of memory, thus starts to |
55 |
swap, load will increase, and make will reduce the jobs. It works |
56 |
pretty well. |
57 |
|
58 |
I've chosen the emerge loadavg limit slightly higher so a heavy ebuild |
59 |
won't starve emerge from running configure phases of parallel ebuilds. |
60 |
|
61 |
Regards, |
62 |
Kai |