On Sunday, 12 July 2020 09:29:08 BST Nikos Chantziaras wrote:
> On 12/07/2020 09:04, William Kenworthy wrote:
> > Hi,
> > 
> >      is there a way to change the MAKEOPTS setting on a running emerge?
> > 
> > I am using "-j 5 -l 4" whilst emerging gcc-9.3 but its creating too much
> > pressure  on memory.  I expect the emerge to take many more hours but
> > complete eventually - but reducing it to "-j2" will help other
> > operations whilst not losing whats already been completed (this is an
> > old atom N330 with 4G ram and is my gateway/router/firewall/snort/...
> > and the overload is starting to affect the network throughput
> > significantly).
> 
> No. But what you can do is lower its nice level to 19, and CPU and IO
> priority to "idle". First, find the process IDs of emerge and make:
> 
>    ps aux | grep emerge
>    ps aux | grep make
> 
> The first number after the user name (which is "root") is the pid. Then
> do the following for both pids:
> 
>    schedtool -D -n 19 pid
>    ionice -c 3 -p pid
> 
> ionice is in sys-apps/util-linux, so it's probably already installed.
> schedtool though is in sys-process/schedtool and it might not be
> installed. Nothing you can do about that right now. You have to wait it
> out. ionice should help a bit though.
> 
> In the future, I *highly* recommend installing schedtool, and then put
> this in your make.conf:
> 
>    PORTAGE_NICENESS=19
>    PORTAGE_IONICE_COMMAND="sh -c \"schedtool -D \${PID}; ionice -c 3 -p
> \${PID}\""
> 
> I have used this for many years now. It makes emerge have a virtually
> imperceptible impact on my system. I can emerge for example gcc or
> libreoffice with -j4 on my 4 cores/4 threads CPU, and I feel no slowdown
> at all. This won't help with running out of RAM obviously, but it helps
> immensely with keeping the system highly responsive.

Another trick to use if the atom is becoming I/O disk bound is:

echo bfq > /sys/block/sda/queue/scheduler

This will have more of an impact if the PC is swapping heavily and the I/O on 
/dev/sda is choking other processes accessing the disk.


> Another thing I recommend is getting rid of "-j5". Use -j4. The "+1"
> recommendation from decades ago does not apply anymore with modern Linux
> kernels. You can test this yourself by emerging a smaller package that
> takes like 2 minutes or so to emerge, and compare times with j4 and j5.
> Most likely you will see no difference, other than j5 using more RAM.

On an older PC with 16G RAM I have noticed the +1 giving marginally faster 
results each time.  I tried repeated compiles of ffmpeg and n+1 or 2(n+1) was 
faster, as long as RAM was not exhausted.  On larger packages/less RAM, 
limiting MAKEOPTS individually would be advisable to avoid William's problem.