> Sanity check time. :) Returning NULL when memory is unavailable is a
> very basic premise, let's not to break something that has been working
> for more than 20 years.
>
> Let me defer to Solaris for a moment. I just ran many, many copies of
> AA's leak.c (posted on l-k a hundred or so messages so) on a Solaris
> 2.6 box, as a normal non-root user. It supports memory overcommit.
> Solaris behaves sanely, IMHO:
According to a Sun engineer, Solaris 2.6 does not support memory overcommit.
Normally Solaris manages memory by reserving virtual memory for all processes,
whether they use utilize it or not. When virtual memory has been fully
reserved, then malloc()'s, fork()'s, etc may then fail with the 'Resource
temporaily unvailable', even though the physical swap may be hardly touched.
If Solaris 2.6 does support memory overcommit, how did you activate it?
> * When malloc needs memory and none is available, it returns NULL
> and sets errno to 'Resource temporarily unavailable'.
> * When not-yet-committed memory wants to be initialized, but cannot due
> to OOM, the process coredumps.
> * _No_ daemons were lost after 30 minutes or so of leak'ing.
>
> This is sane, logical, expected behavior following the
> Principle of Least Surprise.
>
> It of course raises questions about system-critical processes dying; no
> tests were done to this affect under Solaris. But ya gotta handle it.
> Production OS's have to. Yes, even the network layer needs to handle
> OOM situations with some sanity.
>
[deleted]
-- mikeh
-
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/