On 28 Mar 2000 00:26:37 GMT, you wrote:
>On 21 Mar 2000 23:36:59 +0100, Marco Colombo <marco@esi.it> wrote:
>>On Tue, 21 Mar 2000, James Sutherland wrote:
>>
>>[...[
>>> So? If you touch the memory, overcommit doesn't come into play.
>>
>>All processes should do that for it to work. Example (you have 128MB of swap):
>
>Yes. It is easy to force (just overload malloc(3) with small library wrapper
>in /etc/ld.so.preload). Or wrap around brk/sbrk(2).
>
>Problem is, overcommit is just one thing that could lead to OOM.
No. It CANNOT lead to an OOM condition.
>We can discuss that you can lower the chances for OOM by disabling
>overcommit,
No, that makes OOM situations MORE likely.
> implementing efficient per-user-VM quota,
That shifts the problem from a system-level to a user-level problem.
This might be an acceptable "solution" for some, but isn't practical
in many environments (or indeed possible with Linux ATM).
> fixing stack size,
Also makes things worse; instead of a high general limit, you start
hitting lots of much lower limits.
>reserving some memory only for kernel and/or root, etc, but it will just
>lower the chances for OOM, not eliminate it.
>
>OOM will still happen, and we need some handling when it hits us. killing
>random process is at least guaranteed to be fair as far as it goes, but
>fairness is not necessarily the most sane thing to do in all cases...
Not necessarily "killing" - just "signalling". Properly written, a
program should be able to handle the signal and exit gracefully. If it
doesn't handle a "something's wrong" signal, can we expect it to check
every malloc() call for an equivalent return value?
James.
-
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/
This archive was generated by hypermail 2b29 : Fri Mar 31 2000 - 21:00:24 EST