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

[Wil Reichert]

On Tue, Aug 12, 2008 at 8:05 AM, Beso <givemesugarr@×××××.com> wrote:
>
>
> 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
>

Every time you re-install the -bin package you need to re-accept their
license (er whatever, registaration perhaps?) at first run.  Annoys me
enough to compile it myself.