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/