From mboxrd@z Thu Jan 1 00:00:00 1970
Received: from pigeon.gentoo.org ([69.77.167.62] helo=lists.gentoo.org)
by finch.gentoo.org with esmtp (Exim 4.60)
(envelope-from <gentoo-amd64+bounces-9759-garchives=archives.gentoo.org@lists.gentoo.org>)
id 1KSv0r-0003dA-IE
for garchives@archives.gentoo.org; Tue, 12 Aug 2008 14:38:17 +0000
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id D3112E0379;
Tue, 12 Aug 2008 14:38:15 +0000 (UTC)
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2])
by pigeon.gentoo.org (Postfix) with ESMTP id 893ECE0379
for <gentoo-amd64@lists.gentoo.org>; Tue, 12 Aug 2008 14:38:15 +0000 (UTC)
Received: from list by ciao.gmane.org with local (Exim 4.43)
id 1KSv0o-0006O8-Jn
for gentoo-amd64@lists.gentoo.org; Tue, 12 Aug 2008 14:38:14 +0000
Received: from ip68-231-12-43.ph.ph.cox.net ([68.231.12.43])
by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
id 1AlnuQ-0007hv-00
for <gentoo-amd64@lists.gentoo.org>; Tue, 12 Aug 2008 14:38:14 +0000
Received: from 1i5t5.duncan by ip68-231-12-43.ph.ph.cox.net with local (Gmexim 0.1 (Debian))
id 1AlnuQ-0007hv-00
for <gentoo-amd64@lists.gentoo.org>; Tue, 12 Aug 2008 14:38:14 +0000
X-Injected-Via-Gmane: http://gmane.org/
To: gentoo-amd64@lists.gentoo.org
From: Duncan <1i5t5.duncan@cox.net>
Subject: [gentoo-amd64] Re: Symlinks vs. Bind mounts.
Date: Tue, 12 Aug 2008 14:38:08 +0000 (UTC)
Message-ID: <pan.2008.08.12.14.38.07@cox.net>
References: <48A1034E.5030109@gmail.com> <pan.2008.08.12.04.45.48@cox.net>
<48A14131.20904@pp.dyndns.biz> <48A1476D.8020409@gmail.com>
<d257c3560808120130o55c0c805n69bda3ed4cb9a823@mail.gmail.com>
Precedence: bulk
List-Post: <mailto:gentoo-amd64@lists.gentoo.org>
List-Help: <mailto:gentoo-amd64+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-amd64+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-amd64+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-amd64.gentoo.org>
X-BeenThere: gentoo-amd64@lists.gentoo.org
Reply-to: gentoo-amd64@lists.gentoo.org
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
X-Complaints-To: usenet@ger.gmane.org
X-Gmane-NNTP-Posting-Host: ip68-231-12-43.ph.ph.cox.net
User-Agent: Pan/0.133 (House of Butterflies)
Sender: news <news@ger.gmane.org>
Content-Transfer-Encoding: quoted-printable
X-Archives-Salt: 433f7866-f9c4-41c6-9231-540b4d81aa00
X-Archives-Hash: e824fffcac18c396613228cd8e78dc1b
Beso <givemesugarr@gmail.com> posted
d257c3560808120130o55c0c805n69bda3ed4cb9a823@mail.gmail.com, excerpted
below, on Tue, 12 Aug 2008 08:30:44 +0000:
> if you're still using something the kernel won't kill nothing. the
> behaviour you're referencing is the kernel cached pages. when you use
> something you load it into memory. after you finish using it then the
> kernel will continue to hold the pages in ram as cached pages, if you
> have enough space to be able to speed up the eventual future reuse of
> that particular object.
Beso, I think he was referring to being totally out of memory+swap, thus=20
triggering the kernel OOM (out of memory) killer.
Yes, that can happen. However, in practice, at least from my experience,=
=20
before the kernel ever gets to the point of actually killing anything,=20
the system becomes basically unresponsive anyway, as the kernel searches=20
for every last bit of memory it can recover to use for whatever is taking=
=20
it all. I've never had that happen since I switched to /tmp on tmpfs so=20
I don't know how it works in regard to that -- presumably it'd consider=20
it temporary and kill it before killing applications, but I don't know=20
that for sure -- but I did have it happen once when I had swap turned off=
=20
and only a gig of memory -- and tried to scan something at an incredibly=20
high resolution that would have used over a gig of memory for the scan=20
data alone, had I had it there to use! Even with swap turned off, the=20
system was unusable, as the kernel was still looking for every bit of=20
memory it could find some 15 minutes or so into unresponsiveness, when I=20
gave up and hit the reset. I don't know how much longer it would have=20
continued before triggering the OOM killer, but it wasn't worth waiting=20
around to find out.
BTW, I did have a runaway process once some-time later (before I set=20
system per-process memory limits using ulimit, see "help ulimit" at the=20
bash prompt), after I had upgraded to 8 gigs RAM, with 16 gigs swap as 4=20
partitions of 4 gigs each, on 4 different hard drives (with priority set=20
equal so the kernel striped them for 4X swap speed). That worked much=20
better as I didn't let it get quite out of memory before killing it, but=20
I did let the process go long enough to have it eat up the 8 gigs of=20
regular memory plus 15 gigs or so of swap before I killed it, just to see=
=20
how responsive the system remained while nearly 16 gigs into swap after I=
=20
had 4-way striped it. The system was a bit draggy at that, but it was=20
certainly WAY more responsive than that time I let it get totally out of=20
memory with NO swap, and responsive enough that I could still kill the=20
runaway process when I decided it was getting too close to leaving me in=20
the same situation again. (While I let it run until 15 out of 16 gigs=20
swap were used, I had setup a high priority root shell with the kill -9=20
command waiting for me to hit enter... before it got far into swap, just=20
in case.) I'd have hated to have been 16 gigs into swap on a single-
spindle swap system, that's for sure!
So anyway, make sure you have enough memory+swap to compile OOo, and you=20
shouldn't have any major problems. FWIW, I set my max capacity on the=20
tmpfs to 6 GB, since I knew OOo took 5+ gigs as the largest package, tho=20
I've never actually compiled it. And of course with 8 gigs RAM and 16=20
gigs swap, I have 24 gigs mem+swap to play with, and the 6 gig max tmpfs=20
doesn't get anywhere near that, so I'm fine.=20
BTW, Chris G, one of the devs in the game herd, has mentioned that there=20
are a couple game-data packages that actually require more scratch-space=20
to merge than OOo, but of course they aren't compiled, so if the system=20
runs out of room installing them, no big deal, just create a sufficiently=
=20
large temporary swap file or switch PORTAGE_TMPDIR back to disk=20
temporarily, and retry. It's not like you're losing hours of work like=20
would be possible if OOo ran out of room while emerging. Plus at least=20
personally, I don't have to worry about that since the games in question=20
aren't freedomware anyway, so I'd never install them in the first place.
--=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