Re: [PATCH] OOM killer API (was: [PATCH] VM fix for 2.4.0-test9 & OOM handler)

From: Jesse Pollard (
Date: Wed Oct 11 2000 - 09:45:30 EST

--------- Received message begins Here ---------

> 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" ?

Not deleting files, but your system may crash :)

The problem with memory is that the tools are not available (ie already
included in the kernel) to do anything else. In the example of running
out of file space, there are quota limits. You can still run out of space,
but only when the sum of all users quota allocations exceed the disk

Until user memory resource quotas are included in the kernel, there will be
nothing else that can be done. Even with resource quotas, if the total of
active users exceeds the resource then the same/equivalent situation occurs.

What is being done is still necessary, but in the long term it will end
up addressing the case where a single user runs out, rather than the system
as a whole.

User memory resource quota control is needed in large clusters, and in large
systems with multiple users. In a single user environment, resource quotas
are less important than providing a consistant (and hopefully intutitive)
process abort. That keeps the system going, and becomes up to the user to
choose what else may need to be aborted.

Jesse I Pollard, II

Any opinions expressed are solely my own.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

This archive was generated by hypermail 2b29 : Sun Oct 15 2000 - 21:00:17 EST