From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id C1AC11381F3 for ; Sun, 12 Jul 2020 08:59:46 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 747A7E079E; Sun, 12 Jul 2020 08:59:40 +0000 (UTC) Received: from mail-gw.thundermail.uk (mail-gw.thundermail.uk [149.255.60.71]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id C7027E075F for ; Sun, 12 Jul 2020 08:59:39 +0000 (UTC) Received: from mailgw01.thundermail.uk (mail-gw.thundermail.uk [149.255.60.66]) by mail-gw.thundermail.uk (Postfix) with ESMTPS id D07F1604BBA2 for ; Sun, 12 Jul 2020 09:59:37 +0100 (BST) X-ASG-Debug-ID: 1594544377-0554134a29cb13a0001-LfjuLa Received: from cloud307.thundercloud.uk (cloud307.thundercloud.uk [149.255.58.40]) by mailgw01.thundermail.uk with ESMTP id 4Dm30OOk9GyJq5er (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Sun, 12 Jul 2020 09:59:37 +0100 (BST) X-Barracuda-Envelope-From: confabulate@kintzios.com X-Barracuda-Effective-Source-IP: cloud307.thundercloud.uk[149.255.58.40] X-Barracuda-Apparent-Source-IP: 149.255.58.40 Received: from lenovo.localdomain (230.3.169.217.in-addr.arpa [217.169.3.230]) by cloud307.thundercloud.uk (Postfix) with ESMTPSA id 85206C896A3 for ; Sun, 12 Jul 2020 09:59:36 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kintzios.com; s=default; t=1594544376; bh=NJuubjEsSSHqGERkWo917KRBUXQ5n/ldeVOaiVX3ja0=; h=From:To:Subject; b=EWGU6yOvucL7vsRb12zN+W2ZK7AXcMx5HkVochZnB6EnNylwOcVKIY39ySsZ7M7MA ey9o6Gesz/NJSAf2oeli8eWp0nOa480gUuakM95Jw8W3lUlt8O47Wmkz91/8gJ6BC7 +xpz5P/ipmIIC18wi7A4JCeiJMoM1aKdDCKDRe5Q= Authentication-Results: cloud307.thundercloud.uk; spf=pass (sender IP is 217.169.3.230) smtp.mailfrom=confabulate@kintzios.com smtp.helo=lenovo.localdomain Received-SPF: pass (cloud307.thundercloud.uk: connection is authenticated) From: Michael To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Re: Change MAKEOPTS on the fly? Date: Sun, 12 Jul 2020 09:59:35 +0100 X-ASG-Orig-Subj: Re: [gentoo-user] Re: Change MAKEOPTS on the fly? Message-ID: <3312794.iIbC2pHGDl@lenovo.localdomain> In-Reply-To: References: <9621500b-9691-3def-7395-64d68085f5f6@iinet.net.au> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart8623769.CDJkKcVGEf"; micalg="pgp-sha256"; protocol="application/pgp-signature" X-PPP-Message-ID: <20200712085936.41960.67905@cloud307.thundercloud.uk> X-PPP-Vhost: kintzios.com X-Barracuda-Connect: cloud307.thundercloud.uk[149.255.58.40] X-Barracuda-Start-Time: 1594544377 X-Barracuda-Encrypted: ECDHE-RSA-AES128-GCM-SHA256 X-Barracuda-URL: https://149.255.60.66:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at thundermail.uk X-Barracuda-Scan-Msg-Size: 2825 X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=1.9 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.83143 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Archives-Salt: c184df9f-5fce-48a4-a9ed-ef2c426effc9 X-Archives-Hash: 421f63e8fc8cf74199cb395052a806ac --nextPart8623769.CDJkKcVGEf Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="UTF-8" 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. --nextPart8623769.CDJkKcVGEf Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEXqhvaVh2ERicA8Ceseqq9sKVZxkFAl8K0PcACgkQseqq9sKV ZxmVhBAAmvN/SJy4iT1fQ9e+NB9l6dkZrN4kK+7c5H0fYXd8bhNazhK2OVTk8+N6 owfdR+kDeqxpbaT6JmQIdTXfMM9tcD/THcvLCxT2HE8hIZGdJHH39+jkyJtCBKMP 1Szr11BDITggRl8rX2kNuV3/ZNKW3QeNs36/ozUbOMngpzMuFMdwT22W/ICdZSuQ VYhiZ76VQvCUb0CX7fDo9tmOL014MXFelpxaoPmgIVaXffnprCxzs9HaB9B/r9Nj JJxYg+fyBbDwbN8lOcfBkFl14ZHGkRXsyXZ57ngy6J9M4X+7PUQ7Ku5nkfFHWYR7 dXYNrzv/ymcR/lLWmOxCFqbpww6ylAfI2m2uAlgETiARXeIlnao6wXM7L9OVTDa3 5h+noq3oSj08F7Pgy8xbUIlEYeBvzFLB5mPKuK+djKUmIfq3rhfcAwerbLUBNrO5 d5Q+jLzT1nJ4NDSrfoZXOiXnNV8ljsD6A4joJum3U7Z91CSn6L9BAMZW7ctYGliL BtYjhvXCjklLHjIAyA7/Zhh0BZ+9pjLTplTzIgCPFMx+SO/k6Ddme4SAHub4Rsye l3dStHbb62pnT7I+ineInq6wqQqbpSklV2qT6J1MMNS1Nx3m3P6fC9iaaIl2+hkX uUyHcncnn45lSwt2O7pzkkeIIsalC/l29gqotjU0wWMsIjyG7o8= =Td8R -----END PGP SIGNATURE----- --nextPart8623769.CDJkKcVGEf--