From mboxrd@z Thu Jan 1 00:00:00 1970
Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org)
by finch.gentoo.org with esmtp (Exim 4.60)
(envelope-from <gentoo-dev+bounces-48571-garchives=archives.gentoo.org@lists.gentoo.org>)
id 1RPOZf-0000iu-0K
for garchives@archives.gentoo.org; Sun, 13 Nov 2011 01:09:31 +0000
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id D64B121C09A;
Sun, 13 Nov 2011 01:09:20 +0000 (UTC)
Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183])
by pigeon.gentoo.org (Postfix) with ESMTP id B818F21C05A
for <gentoo-dev@lists.gentoo.org>; Sun, 13 Nov 2011 01:08:49 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp.gentoo.org (Postfix) with ESMTP id 3AF801B4013
for <gentoo-dev@lists.gentoo.org>; Sun, 13 Nov 2011 01:08:49 +0000 (UTC)
X-Virus-Scanned: by amavisd-new using ClamAV at gentoo.org
X-Spam-Score: -3.78
X-Spam-Level:
X-Spam-Status: No, score=-3.78 required=5.5 tests=[AWL=0.924, BAYES_00=-1.9,
RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.504]
Received: from smtp.gentoo.org ([127.0.0.1])
by localhost (smtp.gentoo.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id O2UW8PFChe9Q for <gentoo-dev@lists.gentoo.org>;
Sun, 13 Nov 2011 01:08:43 +0000 (UTC)
Received: from lo.gmane.org (lo.gmane.org [80.91.229.12])
by smtp.gentoo.org (Postfix) with ESMTP id 1DE0B1B4001
for <gentoo-dev@gentoo.org>; Sun, 13 Nov 2011 01:08:43 +0000 (UTC)
Received: from list by lo.gmane.org with local (Exim 4.69)
(envelope-from <lnx-gentoo-dev@m.gmane.org>)
id 1RPOYr-0007To-8S
for gentoo-dev@gentoo.org; Sun, 13 Nov 2011 02:08:41 +0100
Received: from ip68-231-22-224.ph.ph.cox.net ([68.231.22.224])
by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
id 1AlnuQ-0007hv-00
for <gentoo-dev@gentoo.org>; Sun, 13 Nov 2011 02:08:41 +0100
Received: from 1i5t5.duncan by ip68-231-22-224.ph.ph.cox.net with local (Gmexim 0.1 (Debian))
id 1AlnuQ-0007hv-00
for <gentoo-dev@gentoo.org>; Sun, 13 Nov 2011 02:08:41 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: gentoo-dev@lists.gentoo.org
From: Duncan <1i5t5.duncan@cox.net>
Subject: [gentoo-dev] Re: have portage be quiet by default
Date: Sun, 13 Nov 2011 01:08:27 +0000 (UTC)
Message-ID: <pan.2011.11.13.01.08.26@cox.net>
References: <4EB4FA98.3080201@gentoo.org> <4EBD42EE.4060104@gentoo.org>
<4EBEF208.5060500@gentoo.org> <201111121840.16686.vapier@gentoo.org>
<CAE1pOi1bs4oWc9wyiKdfyLBMscWTadSbrVdyre_Pgzj2_vFhaQ@mail.gmail.com>
Precedence: bulk
List-Post: <mailto:gentoo-dev@lists.gentoo.org>
List-Help: <mailto:gentoo-dev+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-dev+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org>
X-BeenThere: gentoo-dev@lists.gentoo.org
Reply-to: gentoo-dev@lists.gentoo.org
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
X-Complaints-To: usenet@dough.gmane.org
X-Gmane-NNTP-Posting-Host: ip68-231-22-224.ph.ph.cox.net
User-Agent: Pan/0.135 (Tomorrow I'll Wake Up and Scald Myself with Tea; GIT
bb16cbd /st/portage/src/egit-src/pan2)
Content-Transfer-Encoding: quoted-printable
X-Archives-Salt: 01da6af8-ed1b-4f62-8034-98c677e6bd1d
X-Archives-Hash: 05a326a11974c088d2d594e18173cab3
Hilco Wijbenga posted on Sat, 12 Nov 2011 16:05:36 -0800 as excerpted:
> By the way, is there a noticeable difference in build time (for
> relatively large builds) when logging to the console is off? Not
> important, just curious.
There can be. AFAIK it's not too bad when output is to a vgacon text-
console, but to frame-buffer (kms mode text console or X) tends to be=20
more CPU intensive and to slow things down if you're bottlenecking on CPU=
=20
as is often (but not always, especially on multi-core systems without=20
emerge --jobs set to allow multiple parallel package emerges at once, as=20
well as MAKEOPTS=3D-j, to allow multiple make jobs with a single merge jo=
b)=20
the case. Terminal windows tend to use what a text console framebuffer=20
does, often more, depending on effects and how much is hardware=20
accelerated.
Perhaps the biggest efficiency gain, however, if you have 4 gig plus of=20
memory (and a 64-bit system to handle it reasonably efficiently), is to=20
point PORTAGE_TMPDIR at a tmpfs and control its size and the number of=20
parallel jobs to avoid more than a few MB of swappage. Based on my=20
experience here, with four or even at two cores, the load average doesn't=
=20
bog down the system anywhere close to what disk I/O does, regardless of=20
whether it's swap or conventional disk I/O access. Putting the temp-dir=20
in tmpfs means a lot of scratch files are never written to disk at all,=20
thus saving that disk access, and theoretically it could even save if=20
you're into swap (forums or user list for the details), but obviously far=
=20
less then, so I now set jobs and load average to best control, if=20
indirectly, for memory usage including the tmpfs, as opposed to direct=20
CPU load control.
But there's whole threads on optimizing emerges on the forums and user=20
list. This really isn't the place for further discussion on that.
--=20
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman