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 EFDB8139083 for ; Tue, 5 Dec 2017 10:10:05 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id B9DF6E0F4F; Tue, 5 Dec 2017 10:09:59 +0000 (UTC) Received: from smarthost03a.mail.zen.net.uk (smarthost03a.mail.zen.net.uk [212.23.1.20]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 51B15E0F35 for ; Tue, 5 Dec 2017 10:09:59 +0000 (UTC) Received: from [82.69.80.10] (helo=peak.localnet) by smarthost03a.mail.zen.net.uk with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1eMAAn-0006NM-9K for gentoo-user@lists.gentoo.org; Tue, 05 Dec 2017 10:09:57 +0000 From: Peter Humphrey To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] is multi-core really worth it? Date: Tue, 05 Dec 2017 10:09:56 +0000 Message-ID: <1768467.U8M6HPhz0d@peak> In-Reply-To: References: <6b5fbeca-453c-f103-5e4e-a8db83a6dabf@st.com> <6661527.9k004Oio64@eve> 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 MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Originating-smarthost03a-IP: [82.69.80.10] Feedback-ID: 82.69.80.10 X-Archives-Salt: 2c484385-e1a5-4a54-8233-6c8becd88f5c X-Archives-Hash: d2c1c8c400cbfc8b61da86c661f91245 On Tuesday, 5 December 2017 04:11:17 GMT Taiidan@gmx.com wrote: > On my 16 core opteron I have to do -j32 or sometimes -j64 to be using > everything all the time, is this normal? If I don't do this it won't be > pegged at 100% all the time. On my 12-thread i7 I have -j24 -l60. Most times it's better not to limit the number of jobs, just the load average; then portage loads up the CPU as high as it can. The exception, and even this is debatable, is when you're compiling a large set of packages, say an emerge -e world, in which case so many jobs have been started by the time they're all into compiling that the load soars to silly heights - I've seen 80-odd here. But that's only about seven jobs queued per CPU thread, so maybe it isn't too bad after all. > I assume using a ramdisk would help with this? I wouldn't want to do a > SSD as I assume it would excessively wear by doing compiles. I use tmpfs, like this: $ grep tmpfs /etc/fstab tmpfs /var/tmp/portage tmpfs noatime,uid=portage,gid=portage,mode=0775 0 0 tmpfs /tmp tmpfs noatime,nosuid,nodev,noexec,mode=1777 0 0 If a tmpfs fills up, the excess gets swapped out, but with 32GB RAM here I haven't yet seen any swap used at all - not even in an emerge -e world. I've read that modern SSDs are far less prone to wear than earlier ones, as R0b0t1 suggests. -- Regards, Peter.