1 |
On Sunday, 12 July 2020 09:29:08 BST Nikos Chantziaras wrote: |
2 |
> On 12/07/2020 09:04, William Kenworthy wrote: |
3 |
> > Hi, |
4 |
> > |
5 |
> > is there a way to change the MAKEOPTS setting on a running emerge? |
6 |
> > |
7 |
> > I am using "-j 5 -l 4" whilst emerging gcc-9.3 but its creating too much |
8 |
> > pressure on memory. I expect the emerge to take many more hours but |
9 |
> > complete eventually - but reducing it to "-j2" will help other |
10 |
> > operations whilst not losing whats already been completed (this is an |
11 |
> > old atom N330 with 4G ram and is my gateway/router/firewall/snort/... |
12 |
> > and the overload is starting to affect the network throughput |
13 |
> > significantly). |
14 |
> |
15 |
> No. But what you can do is lower its nice level to 19, and CPU and IO |
16 |
> priority to "idle". First, find the process IDs of emerge and make: |
17 |
> |
18 |
> ps aux | grep emerge |
19 |
> ps aux | grep make |
20 |
> |
21 |
> The first number after the user name (which is "root") is the pid. Then |
22 |
> do the following for both pids: |
23 |
> |
24 |
> schedtool -D -n 19 pid |
25 |
> ionice -c 3 -p pid |
26 |
> |
27 |
> ionice is in sys-apps/util-linux, so it's probably already installed. |
28 |
> schedtool though is in sys-process/schedtool and it might not be |
29 |
> installed. Nothing you can do about that right now. You have to wait it |
30 |
> out. ionice should help a bit though. |
31 |
> |
32 |
> In the future, I *highly* recommend installing schedtool, and then put |
33 |
> this in your make.conf: |
34 |
> |
35 |
> PORTAGE_NICENESS=19 |
36 |
> PORTAGE_IONICE_COMMAND="sh -c \"schedtool -D \${PID}; ionice -c 3 -p |
37 |
> \${PID}\"" |
38 |
> |
39 |
> I have used this for many years now. It makes emerge have a virtually |
40 |
> imperceptible impact on my system. I can emerge for example gcc or |
41 |
> libreoffice with -j4 on my 4 cores/4 threads CPU, and I feel no slowdown |
42 |
> at all. This won't help with running out of RAM obviously, but it helps |
43 |
> immensely with keeping the system highly responsive. |
44 |
|
45 |
Another trick to use if the atom is becoming I/O disk bound is: |
46 |
|
47 |
echo bfq > /sys/block/sda/queue/scheduler |
48 |
|
49 |
This will have more of an impact if the PC is swapping heavily and the I/O on |
50 |
/dev/sda is choking other processes accessing the disk. |
51 |
|
52 |
|
53 |
> Another thing I recommend is getting rid of "-j5". Use -j4. The "+1" |
54 |
> recommendation from decades ago does not apply anymore with modern Linux |
55 |
> kernels. You can test this yourself by emerging a smaller package that |
56 |
> takes like 2 minutes or so to emerge, and compare times with j4 and j5. |
57 |
> Most likely you will see no difference, other than j5 using more RAM. |
58 |
|
59 |
On an older PC with 16G RAM I have noticed the +1 giving marginally faster |
60 |
results each time. I tried repeated compiles of ffmpeg and n+1 or 2(n+1) was |
61 |
faster, as long as RAM was not exhausted. On larger packages/less RAM, |
62 |
limiting MAKEOPTS individually would be advisable to avoid William's problem. |