[gentoo-amd64] Re: Symlinks vs. Bind mounts.

[Duncan]

Beso <givemesugarr@×××××.com> posted
d257c3560808120130o55c0c805n69bda3ed4cb9a823@××××××××××.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 
triggering the kernel OOM (out of memory) killer.

Yes, that can happen.  However, in practice, at least from my experience, 
before the kernel ever gets to the point of actually killing anything, 
the system becomes basically unresponsive anyway, as the kernel searches 
for every last bit of memory it can recover to use for whatever is taking 
it all.  I've never had that happen since I switched to /tmp on tmpfs so 
I don't know how it works in regard to that -- presumably it'd consider 
it temporary and kill it before killing applications, but I don't know 
that for sure -- but I did have it happen once when I had swap turned off 
and only a gig of memory -- and tried to scan something at an incredibly 
high resolution that would have used over a gig of memory for the scan 
data alone, had I had it there to use!  Even with swap turned off, the 
system was unusable, as the kernel was still looking for every bit of 
memory it could find some 15 minutes or so into unresponsiveness, when I 
gave up and hit the reset.  I don't know how much longer it would have 
continued before triggering the OOM killer, but it wasn't worth waiting 
around to find out.

BTW, I did have a runaway process once some-time later (before I set 
system per-process memory limits using ulimit, see "help ulimit" at the 
bash prompt), after I had upgraded to 8 gigs RAM, with 16 gigs swap as 4 
partitions of 4 gigs each, on 4 different hard drives (with priority set 
equal so the kernel striped them for 4X swap speed).  That worked much 
better as I didn't let it get quite out of memory before killing it, but 
I did let the process go long enough to have it eat up the 8 gigs of 
regular memory plus 15 gigs or so of swap before I killed it, just to see 
how responsive the system remained while nearly 16 gigs into swap after I 
had 4-way striped it.  The system was a bit draggy at that, but it was 
certainly WAY more responsive than that time I let it get totally out of 
memory with NO swap, and responsive enough that I could still kill the 
runaway process when I decided it was getting too close to leaving me in 
the same situation again.  (While I let it run until 15 out of 16 gigs 
swap were used, I had setup a high priority root shell with the kill -9 
command waiting for me to hit enter... before it got far into swap, just 
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 
shouldn't have any major problems.  FWIW, I set my max capacity on the 
tmpfs to 6 GB, since I knew OOo took 5+ gigs as the largest package, tho 
I've never actually compiled it.  And of course with 8 gigs RAM and 16 
gigs swap, I have 24 gigs mem+swap to play with, and the 6 gig max tmpfs 
doesn't get anywhere near that, so I'm fine. 

BTW, Chris G, one of the devs in the game herd, has mentioned that there 
are a couple game-data packages that actually require more scratch-space 
to merge than OOo, but of course they aren't compiled, so if the system 
runs out of room installing them, no big deal, just create a sufficiently 
large temporary swap file or switch PORTAGE_TMPDIR back to disk 
temporarily, and retry.  It's not like you're losing hours of work like 
would be possible if OOo ran out of room while emerging.  Plus at least 
personally, I don't have to worry about that since the games in question 
aren't freedomware anyway, so I'd never install them in the first place.

-- 
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