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.
signature.asc
Description: This is a digitally signed message part.
