On Tue, Aug 12, 2008 at 8:05 AM, Beso <[EMAIL PROTECTED]> wrote: > > > 2008/8/12 Duncan <[EMAIL PROTECTED]> >> >> Beso <[EMAIL PROTECTED]> posted >> [EMAIL PROTECTED], 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.
