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 30863139083 for ; Tue, 5 Dec 2017 13:07:29 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id E2F4CE0FE0; Tue, 5 Dec 2017 13:07:19 +0000 (UTC) Received: from smarthost01b.mail.zen.net.uk (smarthost01b.mail.zen.net.uk [212.23.1.3]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 7D2C1E0FCA for ; Tue, 5 Dec 2017 13:07:19 +0000 (UTC) Received: from [82.69.80.10] (helo=peak.localnet) by smarthost01b.mail.zen.net.uk with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1eMCwP-0008Rd-E6 for gentoo-user@lists.gentoo.org; Tue, 05 Dec 2017 13:07:17 +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 13:07:16 +0000 Message-ID: <7155996.JnYQhvlp2Z@peak> In-Reply-To: <5A267913.5030902@youngman.org.uk> References: <6b5fbeca-453c-f103-5e4e-a8db83a6dabf@st.com> <1768467.U8M6HPhz0d@peak> <5A267913.5030902@youngman.org.uk> 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-smarthost01b-IP: [82.69.80.10] Feedback-ID: 82.69.80.10 X-Archives-Salt: 8b32fed3-e410-4c27-a37d-aa1119a44329 X-Archives-Hash: b52608c13498309f863dc5dfb38456a1 On Tuesday, 5 December 2017 10:46:43 GMT Wols Lists wrote: > On 05/12/17 10:09, Peter Humphrey wrote: > >> 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. > Same here. Note that tmpfs defaults to half ram, so that would give you > a 16GB /var/tmp/portage. That's the starting size, yes. The kernel will expand it or shrink it with changes in the demands on the system. > With 16GB ram here, that would probably cause things like emerging > libreoffice or firefox or gcc to abort. Not unless you run out of swap space - remember that tmpfs gets swapped like anything else in memory. Or unless one compile job requires a single temporary file bigger than your tmpfs file system, which hardly seems likely. > My fstab has these lines ... note the SIZE option ... Yes, I know about the size option. I haven't needed to use it on this box. > # glibc 2.2 and above expects tmpfs to be mounted at /dev/shm for > # POSIX shared memory (shm_open, shm_unlink). > # (tmpfs is a dynamically expandable/shrinkable ramdisk, and will > # use almost no memory if not populated with files) > shm /dev/shm tmpfs > nodev,nosuid,noexec 0 0 You shouldn't need that shm entry any more. > portage /var/tmp/portage tmpfs > size=30G,mode=0777 0 0 > tmp /tmp tmpfs > size=10G,mode=0777 0 0 > > My swap partitions are twice max ram, so I currently have two 32GB > partitions giving me 80GB total ram and swap. So you shouldn't find big compiler jobs aborting on out-of-memory. > (My new system when I get it working maxes out at 64GB ram so I'll have > 256GB swap and (currently) 16GB ram) I've halved my original 4GB swap to 2GB since it never seems to be used. I'm not brave enough to do away with it altogether though. -- Regards, Peter.