Messages in this thread | | | Date | Fri, 16 Jul 1999 17:02:55 +0200 (MEST) | From | <> | Subject | Re: Memory hogs |
| |
Rik van Riel wrote: > Please don't. My little algorithm (with no overhead on a normal > system) works great -- it has been tested by simulation folks > who want a 16MB netscape killed in favor of their week-old, > 150MB simulation.
Ok, I'll adapt your patch. The only gripe I have is that it doesn't send out warning shoots before, that allow tasks to quit nicely. As I said, even the X server can be the cause of a OOM condition, and if the algorithm works fine, it is rightly shot. Even though a lot of other processes might go down before (most of them are likely to die after X is shot, either). But I think another out of memory check (with lower limits, and SIGQUIT instead of SIGKILL) can solve that.
Choosing a good algorithm is important, since I can well remember us bastard students from hell kicking out other's week-long running simulations with a clever written memory hog program (on HP workstations: HP-UX doesn't overcommit and kicks out last allocater. The hog allocated all available pages (with raw sbrk()) and then you just have to wait until the long-running job needs a new page - and your workstation was unloaded ;-).
My algorithm was more intented to work against real memory hoggers (DOS attacks from the BSfHs, processes going wild), not against creeping memory consumption, such as with large simulations growing larger and larger, and finally kicking themselves out of memory (or - as you propose - kicking out other's apps). If memory shortage is a normal operation condition, you really should enlarge your swap-file.
-- Bernd Paysan "If you want it done right, you have to do it yourself" http://www.jwdt.com/~paysan/
Sent through Global Message Exchange - http://www.gmx.net
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |