On 2016-05-13 09:34, Sebastian Frias wrote:
Hi Austin,
On 05/13/2016 03:11 PM, Austin S. Hemmelgarn wrote:
On 2016-05-13 08:39, Sebastian Frias wrote:
My point is that it seems to be possible to deal with such conditions in a more controlled way, ie: a way that is less random and less abrupt.
There's an option for the OOM-killer to just kill the allocating task instead of using the scoring heuristic. This is about as deterministic as things can get though.
By the way, why does it has to "kill" anything in that case?
I mean, shouldn't it just tell the allocating task that there's not enough memory by letting malloc return NULL?
In theory, that's a great idea. In practice though, it only works if:
1. The allocating task correctly handles malloc() (or whatever other
function it uses) returning NULL, which a number of programs don't.
2. The task actually has fallback options for memory limits. Many
programs that do handle getting a NULL pointer from malloc() handle it
by exiting anyway, so there's not as much value in this case.
3. There isn't a memory leak somewhere on the system. Killing the
allocating task doesn't help much if this is the case of course.
You have to keep in mind though, that on a properly provisioned system,
the only situations where the OOM killer should be invoked are when
there's a memory leak, or when someone is intentionally trying to DoS
the system through memory exhaustion. If you're hitting the OOM killer
for any other reason than those or a kernel bug, then you just need more
memory or more swap space.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>