Messages in this thread | | | Date | Wed, 11 Oct 2000 19:53:50 -0700 (PDT) | From | <> | Subject | Re: [PATCH] OOM killer API (was: [PATCH] VM fix for 2.4.0-test9 & OOM handler) |
| |
I've had to support an app running as a back-end to a webserver that would malloc() different amounts of memory depending on user input, up to multiple gigabytes of memory which vastly exceeded the 512k the machine had as main memory. The app was a program that would scan genetic sequence looking for 'repeats' in the sequence, and one sequence would malloc a hundred megs while a similar sequence of the same size would cause the algorithm to try to malloc over a gig. Part of the algorithm was actually to simply try to malloc all the memory it could and if it ran out, it would bump down the resolution that it was scanning with and try again. And it would regularly push the machine into OOM and take it down because daemons got killed long before the OOM killer got around to taking out the process that was malloc()ing all the memory. On other machines I'd set RLIMIT_DATA and my OOM problems went away, but on linux this didn't work (and i wasn't comfortable enough with kernel sources back then to manage to find RLIMIT_AS).
On Thu, 12 Oct 2000, Matthew Hawkins wrote: > Heh.. now all we need is some smart-arse to make something similar to > apply to the _entire_ VM subsystem, and both Rik and Andrea can be happy > ;) > > Seriously, am I missing something obvious or is it far simpler just to > keel over and die if the system goes OOM? I mean, seriously, if the > administrator lets it get to that state then he/she/it deserves a dead > system. It's akin to having your car run out of petrol - you don't > start shooting passengers because their extra load made the engine chew > more. You pack up your kitty and go to the nearest petrol station and > buy more, plug it into the car then learn from the experience so this > fringe case of it happening doesn't happen again. I don't really see > much difference between a car going "OOP" and a computer going OOM. > Should we start deleting files according to some randomly-chosen > heueristic if a filesystem goes "OOS" ? > >
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
| |