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

[Beso]

2008/8/12 Duncan <1i5t5.duncan@×××.net>

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

does it really worth to compile OOo instead of just downloading the bin
version?! the last time i've tried it the ammount of space taken "hostage",
the slowness of compilation and the really small improvement in speed (as
well as the other deps to install) made me chose the 32bit precompiled bin
package.


dott. ing. beso