Gentoo Archives: gentoo-user

From: Dale <rdalek1967@×××××.com>
To: gentoo-user@l.g.o
Subject: Re: [gentoo-user] per package parallel build
Date: Fri, 25 Oct 2019 17:02:08
Message-Id: b38d359a-1713-030f-67ba-08bf3a576cc1@gmail.com
In Reply to: Re: [gentoo-user] per package parallel build by Mick
1 Mick wrote:
2 > On Friday, 25 October 2019 06:31:03 BST Raffaele BELARDI wrote:
3 >> 8-core CPU:
4 >>
5 >> EMERGE_DEFAULT_OPTS="--quiet-build --keep-going --jobs 9 --load-average 9"
6 >>
7 >> MAKEOPTS="-j9 -l9"
8 >>
9 >> Works fine except when both Firefox and Thunderbird need update, in that
10 >> case emerge typically tries to build them in parallel and one gets OOM
11 >> killed due to insufficient swap space (1G swap, 16G RAM). I will increase
12 >> the swap but I'd like to know: Is there a way to tell emerge to normally
13 >> run 9 parallel jobs but limit to 1 when it is building one of the two
14 >> monsters?
15 >>
16 >> Thanks,
17 >>
18 >> raffaele
19 > Good advice has already been given, but here are some supporting thoughts
20 > based on my experience of trying to emerge mammoth builds on old systems with
21 > low RAM.
22 >
23 > I can't recall how much memory each thread of a FF or TB compile chews up, but
24 > if you allow for up to 2G per thread, with -j9 your 16G RAM *will* be
25 > exhausted at some point. Swapping will commence then in earnest and a I/O
26 > offloading of RAM into swap and back again as threads gasp for adequate memory
27 > will be sustained, while demand for more RAM than available is present. This
28 > creates a bottleneck which will prolong the emerge duration. With enough swap
29 > you won't suffer any more OOMs, but you could find emerge times increase
30 > exponentially. Therefore reducing the total number of jobs for these two
31 > packages will help in both cases.
32 >
33 > Setting up an env directive as already advised in previous responses to
34 > restrict both packages to fewer jobs will work, but in some cases it can be
35 > suboptimal. When only one package needs updating, why should it be emerged at
36 > a lesser speed than your system can support? Even when both packages are
37 > emerged at the same time, the memory crunch may only take place for a limited
38 > period, at a time when both packages will be using maximum memory per thread.
39 > To make matters worse ebuilds and source code changes, compilers change and
40 > trying to optimise your emerge soon becomes a moving beast, so some
41 > experimentation will be necessary.
42 >
43 > I think reducing your job/load count to 1 would be excessive. Reducing it
44 > down to 5 ought to be adequate, but I suggest to increase your swap. You
45 > could just use a swap file for this purpose.
46 >
47 > PS. In an ideal AI world, portage would know how much memory is necessary for
48 > a given package and would auto-adjust the number of jobs to minimise swapping
49 > given any amount of RAM. In an even more ideal world, it would be able to do
50 > this in real time. :-)
51 >
52
53
54 I agree that it would be nice if emerge could do that automatically,
55 although I have no clue how to do that or even if it can be done at
56 all.  Back when I had less memory, I could let FF, LOo or another
57 package run at full speed but only if it was only one of those packages
58 at a time.  Thing is, on occasion two or more of those updates would hit
59 and due to the long compile times, end up compiling at the same time. 
60 Do you think there is a way for the devs to set up a method to tell
61 emerge not to emerge certain packages at the same time?  In other words,
62 if Firefox is emerging, LOo is held until it is done or vice versa. 
63 Maybe even have it so others can be listed.  The list of large packages
64 are likely small but they can have a huge impact on systems with less
65 memory. 
66
67 You think that a feature worth asking the devs about?  Maybe they can
68 figure out a way to implement that??
69
70 Dale
71
72 :-)  :-) 

Replies

Subject Author
Re: [gentoo-user] per package parallel build Mick <michaelkintzios@×××××.com>
Re: [gentoo-user] per package parallel build John Blinka <john.blinka@×××××.com>