Tiny Core Extensions > TCE Talk

adding new programms to compiletc

<< < (3/6) > >>

Jason W:
Linux OOM killer is one such thing that shuts down a process before memory is exhausted and lockup occurs, but of course it can't read minds and the complaints I've read about is that it shuts down the wrong process or too many processes.  It tries to aim at the offending process that is gobbling memory.  I have also seen scripts that do the same thing.

I have to admit that when running with tce's and no /usr/local mounting I have in the past locked up my system while either compiling or simply untarring a kernel.  Compiling glibc totally in RAM on a system with 1GB memory and no swap ground it to a halt.  The solution of course is to use storage media to untar and build on and use tclocal or tcz's.  I rarely do anything totally in RAM except on the above mentioned1GB Windows only machine I sometimes have use of that has no working usb ports. 

For a remote server that you only have access through ssh or some other means and no physical access to, having the system shut down a process before locking up allowing you to ssh into it, free some memory or take care of other issues, and restart the process may be of some value.  In that case a hard lockup is the worst case scenario.

tobiaus:
no offense taken, i'm just glad you didn't phrase it "dumb idea." that was kind.

ideally i agree with you, but when the only choice is waiting (literally) an hour for a process that never frees up the ram, or the os cuts off something using all the ram, i'll take the latter. a really great compromise was the os said "hey, i'm about to run out of ram. should i just assume that's what you want or do you want me to kill the process before you're unable to?"

as often as it happened, that would be great.

but as someone mentioned, swap helps too. in any case something so very "wouldn't it be nice" was intended only as such. wishful thinking, not a formal rfc. your idea is good, i like the combination of yours and mine the best, and there's probably some way to make it even better than that. just don't think it was very serious, it was only a thought :) jason: thanks for mentioning oom, never heard of it. if they take mikshaws idea that could improve it.

curaga:
You can also monitor your ram usage by uncommenting the monitor call in your .jwmrc-tray, which by default will show percentage and update every 1.5s.

Juanito:
..and BTW the "..0%S" works nicely with no swap now - thanks

tobiaus:

--- Quote from: curaga on December 17, 2008, 06:41:38 AM ---You can also monitor your ram usage by uncommenting the monitor call in your .jwmrc-tray, which by default will show percentage and update every 1.5s.

--- End quote ---

conky is doing a fine job of that. it doesn't become a problem so much because of not monitoring, but because an application, usually a browser (i tried different ones, dillo did it more than firefox!) would not want to surf too much without hogging all the ram, even if i cleared the cache, history, turned off picture loading. this was more of a problem with dsl and 2.4 kernels (whether by cause or coincidence) although it happened with dsl-n too. i'm happy to say tc seems a lot better about it. maybe ff3 is more stable than the versions of ff2 i was using with dsl? seems likely. although i liked ff2 a lot.

Navigation

[0] Message Index

[#] Next page

[*] Previous page